Hide Forgot
This removes symbols from the debugging table (.symtab) but still exports them so you can link against them (.dynsym section). Pointed out by Jakub and experimentally verified, I can link to a symbol that isn't exported. Removing symbols from .symtab is totally useless, it's just the same as stripping the library. From the docs, -export-symbols is supposed to keep the symbol private to the library, not strip it out of the debugging info. Use "nm -D" to check whether a symbol is exported.
When we get around to marking must-fix for next release, this one should be must-fix; we need this feature to avoid shipping with a bunch of private symbols in the new GTK libraries.
I can reproduce the problem with the trivial libhello.so shared lib example from the autobook. % cat hello.c #include <stdio.h> void hello (char *who) { printf ("Hello, %s!\n", who); } % libtool gcc -c hello.c rm -f .libs/hello.lo gcc -c hello.c -fPIC -DPIC -o .libs/hello.lo gcc -c hello.c -o hello.o >/dev/null 2>&1 mv -f .libs/hello.lo hello.lo % cat hello.symbs hello % libtool gcc -rpath /usr/local/lib -o libhello.la hello.lo rm -fr .libs/libhello.la .libs/libhello.* .libs/libhello.* i386-redhat-linux-gcc -shared hello.lo -Wl,-soname -Wl,libhello.so.0 -Wl,-retain-symbols-file -Wl,hello.symbs -o .libs/libhello.so.0.0.0 (cd .libs && rm -f libhello.so.0 && ln -s libhello.so.0.0.0 libhello.so.0) (cd .libs && rm -f libhello.so && ln -s libhello.so.0.0.0 libhello.so) ar cru .libs/libhello.a hello.o ranlib .libs/libhello.a creating libhello.la (cd .libs && rm -f libhello.la && ln -s ../libhello.la libhello.la) As you can see the effect of "-export-symbols FILE" is for libtool to pass "-Wl,-retain-symbols-file -Wl,FILE" to the linker. Is that not the right thing to do?
I should have added: % nm -a .libs/libhello.so lists only hello (plus unnamed stuff?), but # na -D .libs/libhello.so lists about a dozen symbols.
Right, that's the point. It should be making "nm -D" not output "hello" - here are the libtool docs: `-export-dynamic' Allow symbols from OUTPUT-FILE to be resolved with `dlsym' (*note Dlopened modules::). `-export-symbols SYMFILE' Tells the linker to export only the symbols listed in SYMFILE. The symbol file should end in `.sym' and must contain the name of one symbol per line. This option has no effect on some platforms. By default all symbols are exported. I don't see how removing the symbol from .symtab can be considered "making it not exported," really. Maybe that's what -export-symbols is intended to do but if so it's bizarre... I was hoping the libtool maintainers would respond and clarify however.
Ah, just got another piece of information by coincidence: on Solaris, trying to use the symbols GTK has in its -export-symbols-regex results in a link error, as expected.
I got that backward, trying to use the symbols _not_ in the -export-symbols-regex results in a link error. On Linux, you can happily link to them, no problem.
If you have access to a Solaris machine, could you send me the command sequence libtool generates there. Is the above result using GNU tools or Sun's own compiler/linker? What I was trying to hint at above is that it could be a linker bug, no? Any comments, Jakub?
I don't have Solaris, I was just coincidentally talking to one of the GNOME guys from Sun, who was building GNOME and got a link error because Nautilus tried to use a not-supposed-to-be-exported GTK symbol. I'm pretty sure this is with the native Solaris toolchain.
Oops, found a typo in my initial reply. The second libtool command should of course read: % libtool gcc -export-symbols hello.symbs -rpath /usr/local\/lib -o libhello.la hello.lo
On Solaris 2.5.1 with gcc-2.8.1 but native linker, the output from this command is: $ libtool gcc -export-symbols hello.symbs -rpath /usr/local\/lib -o libhello.la hello.lo rm -fr .libs/libhello.la .libs/libhello.* .libs/libhello.* /usr/ucb/echo "{ global:" > .libs/libhello.so.0.0.0.exp cat hello.symbs | sed -e "s/\(.*\)/\1;/" >> .libs/libhello.so.0.0.0.exp /usr/ucb/echo "local: *; };" >> .libs/libhello.so.0.0.0.exp /usr/ccs/bin/ld -G -M .libs/libhello.so.0.0.0.exp -h libhello.so.0 -o .libs/li\bhello.so.0.0.0 hello.lo -lc rm -f .libs/libhello.so.0.0.0.exp (cd .libs && rm -f libhello.so.0 && ln -s libhello.so.0.0.0 libhello.so.0) (cd .libs && rm -f libhello.so && ln -s libhello.so.0.0.0 libhello.so) ar cru .libs/libhello.a hello.o ranlib .libs/libhello.a creating libhello.la (cd .libs && rm -f libhello.la && ln -s ../libhello.la libhello.la) $ nm -g .libs/libhello.so .libs/libhello.so: [Index] Value Size Type Bind Other Shndx Name [27] | 66740| 0|OBJT |GLOB |0 |12 |_DYNAMIC [25] | 66668| 0|OBJT |GLOB |0 |10 |_GLOBAL_OFFSET_TABLE_ [30] | 66676| 0|OBJT |GLOB |0 |11 |_PROCEDURE_LINKAGE_TABLE\_ [29] | 66892| 0|OBJT |GLOB |0 |12 |_edata [24] | 66892| 0|OBJT |GLOB |0 |13 |_end [31] | 1132| 0|OBJT |GLOB |0 |9 |_etext [26] | 1052| 64|FUNC |GLOB |0 |8 |hello [28] | 0| 0|FUNC |GLOB |0 |UNDEF |printf
jakub has sent a patch to the binutils list that allows anonymous versioning of symbols by ld with a symbol map file. Assuming the feature is added, then next libtool needs to be patched to make use of it when using binutils.
Actually, it needs to be done in a portable way, ie. check whether ld supports anonymous version tags and if yes, use it, otherwise fall back to --retain-symbols-file or nothing.
James Henstridge <james@daa.com.au> posted some patches related to this: http://mail.gnome.org/archives/gtk-devel-list/2002-July/msg00151.html
Unfortunately two tests (mdemo-make.test and dryrun.test) fail with http://www.daa.com.au/~james/files/libtool-1.4.2-expsym-linux.patch applied. Will look into this further.
Btw the same goes for http://www.daa.com.au/~james/files/libtool-1.4.2-expsym.patch
(cc'ing james)
Both of those patches leave a .ver file in the .libs/ directory. Might that be the cause of the problem?
I just did the following: tar xzf libtool-1.4.2.tar.gz cd libtool-1.4.2 patch -p1 < ../libtool-1.4.2-expsym-linux.patch ./configure --prefix=/usr make check And all tests passed (and yes, the libtool script got rebuilt with the libtool.m4 changes).
Thanks for the fast response, James. Ok, with RHL 7.3 there seems to be no problem, but in our current beta environment the test failures are occurring.
Cc'ing Alex too.
James Henstridge's expsym patch is in libtool-1.5-1, so hopefully this resolves the problem finally.