Re: version scripts and symbol prefixes
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 [EMAIL PROTECTED]@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
Index: libtool.m4
===
RCS file: /sources/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.177
diff -u -r1.314.2.177 libtool.m4
--- libtool.m4 28 May 2007 07:03:50 - 1.314.2.177
+++ libtool.m4 30 May 2007 06:33:26 -
@@ -5707,7 +5707,14 @@
if test $supports_anon_versioning = yes; then
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo { global: $output_objdir/$libname.ver~
+case $host in
+bfin-linux*)
+ cat $export_symbols | sed -s s,^,_, -e s/\(.*\)/\1;/ $output_objdir/$libname.ver~
+ ;;
+*)
cat $export_symbols | sed -e s/\(.*\)/\1;/ $output_objdir/$libname.ver~
+ ;;
+esac
$echo local: *; }; $output_objdir/$libname.ver~
$CC '$tmp_sharedflag$tmp_addflag' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-version-script ${wl}$output_objdir/$libname.ver -o $lib'
fi
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: version scripts and symbol prefixes
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 [EMAIL PROTECTED]@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. ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
dlfcn.h (libtool 1.5.23b)
I don't know whether this is a bug or not ... I'm on: $ uname -a HP-UX omztdv1 B.11.23 U ia64 2505142627 unlimited-user license $ libtool --version ltmain.sh (GNU libtool) 1.5.23b (1.1220.2.437 2007/02/17 09:08:45) $ automake --version automake (GNU automake) 1.10 $ autoconf --version autoconf (GNU Autoconf) 2.61 I'm getting this output when running configure: checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... no configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: dlfcn.h: proceeding with the compiler's result checking for dlfcn.h... yes checking how to run the C++ preprocessor... aCC +DD64 -Wl,+k -E In the corresponding config.log is this: configure:6055: checking for unistd.h configure:6076: aCC +DD64 -Wl,+k -c -g conftest.cpp 5 configure:6082: $? = 0 configure:6098: result: yes configure:6125: checking dlfcn.h usability configure:6142: aCC +DD64 -Wl,+k -c -g conftest.cpp 5 configure:6148: $? = 0 configure:6162: result: yes configure:6166: checking dlfcn.h presence configure:6181: conftest.cpp ../configure[6182]: conftest.cpp: not found. configure:6187: $? = 127 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME impact-transport | #define PACKAGE_TARNAME impact-transport | #define PACKAGE_VERSION 2007.2.38 | #define PACKAGE_STRING impact-transport 2007.2.38 | #define PACKAGE_BUGREPORT [EMAIL PROTECTED] | #define PACKAGE impact-transport | #define VERSION 2007.2.38 | #define YYTEXT_POINTER 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | /* end confdefs.h. */ | #include dlfcn.h configure:6201: result: no configure:6207: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor! configure:6209: WARNING: dlfcn.h: proceeding with the compiler's result configure:6234: checking for dlfcn.h configure:6242: result: yes configure:6265: checking how to run the C++ preprocessor configure:6301: aCC +DD64 -Wl,+k -E conftest.cpp I assume this was brought in from using libtool: # _LT_AC_CHECK_DLFCN # -- AC_DEFUN([_LT_AC_CHECK_DLFCN], [AC_CHECK_HEADERS(dlfcn.h)dnl ])# _LT_AC_CHECK_DLFCN My configure.ac includes: AC_PROG_LIBTOOL ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
