Re: version scripts and symbol prefixes

[Peter O'Gorman]

On Wed, 2007-05-30 at 01:32 -0400, Mike Frysinger wrote:
> On Tuesday 29 May 2007, Peter O'Gorman wrote:
> > On Tue, 2007-05-29 at 19:17 -0400, Mike Frysinger wrote:
> > > On Tuesday 29 May 2007, Peter O'Gorman wrote:
> > > > On May 29, 2007, at 1:59 AM, Mike Frysinger wrote:
> > > > > i just came across libupnp which uses some libtool functionality to
> > > > > generate a
> > > > > list of exported symbols and pass it to ld so that only the ones
> > > > > that are
> > > > > part of the ABI get exported ... however, this code doesnt take
> > > > > symbol prefixes into account so in my case, the generated library
> > > > > doesnt include any
> > > > > global symbols ;(
> > > > >
> > > > > libupnp is using libtool-1.5.22 but a quick glance at current CVS
> > > > > head indicates this is still a problem ... can someone correct me ? 
> > > > > i'd just run
> > > > > a small cpp test and see what __USER_LABEL_PREFIX__ is set to ..
> > > > > gcc always
> > > > > defines this and in my case, it's:
> > > > > #define __USER_LABEL_PREFIX__ _
> > > > > unless someone has some cool ld/as/string foo to perform a similar
> > > > > test on
> > > > > object code ...
> > > >
> > > > What system are you running on?
> > >
> > > build = powerpc-linux-gnu
> > > host = bfin-linux-uclibc
> >
> > Ok, currently libtool "checks for" that underscore by looking at the
> > host_os. Using __USER_LABEL_PREFIX__ when building with gcc seems like a
> > much better plan.
> >
> > I'll try to make some libtool time this week and come up with a patch
> > for this. In the meantime, look at libtool.m4 and see how interix and
> > darwin deal with this issue, maybe you can come up with something that
> > will work for your host. Look for 's,^,_,' to find it.
> 
> actually, i toyed around a little more, and i think there might be a bug in 
> the existing code ...
> 
> in the function AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE, it does a dynamic test 
> for "" and "_" in order to set global_symbol_pipe properly ... this is 
> supposed to generate both the raw symbol and the C symbol (which in my case 
> it works: it detects the raw symbol as _FOO and the C symbol as FOO).  btw, 
> if that loop fails, global_symbol_pipe is set to "" which causes syntax 
> errors later ... maybe an early sanity check is needed
> 
> however, the code to generate the version script to give to ld takes this 
> output and only uses the last item in the list (the C symbol) rather than the 
> first item in the list (the raw symbol).  normally this is irrelevant as the 
> symbols are the same (no symbol prefix), but in my case no good :)
> 
> so shouldnt the default export_symbol_cmds be changed from:
> _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | 
> $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols'
> 
> to (something like):
> _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | 
> $global_symbol_pipe | $SED '\'s/[^ ]* \(_[^ ]*\) .*/\1/\'' | sort | uniq > 
> $export_symbols'
> 
> or is there more to it ?
> 
> also, perhaps a sep topic, but in the case of libupnp (and ive seen a few 
> others) which use the -export-symbols-regex, perhaps it'd be appropriate to 
> AC_SUBST() the symbol prefix ?  that way, package people can do:
> -export-symbols-regex "address@hidden@ixml.*"
> and in my case i get:
> -export-symbols-regex "^_ixml.*"
> -mike

A patch like this one should "just work", including for
-export-symbols-regex (it does on darwin).

Peter

bfin.patch
Description: Text Data