Re: version scripts and symbol prefixes

[Mike Frysinger]

On Wednesday 30 May 2007, Peter O'Gorman wrote:
> 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.*"
>
> A patch like this one should "just work", including for
> -export-symbols-regex (it does on darwin).

in other words, i tried too hard ? :)

thanks
-mike

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