Re: version scripts and symbol prefixes

[Mike Frysinger]

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

signature.asc
Description: This is a digitally signed message part.