Bug 55607 - libtool -export-symbols option does the wrong thing
Summary: libtool -export-symbols option does the wrong thing
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: libtool   
(Show other bugs)
Version: 1.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-02 21:08 UTC by Havoc Pennington
Modified: 2007-04-18 16:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-07-08 11:53:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Havoc Pennington 2001-11-02 21:08:54 UTC
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.

Comment 1 Havoc Pennington 2001-12-07 21:37:29 UTC
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.

Comment 2 Jens Petersen 2001-12-10 09:05:08 UTC
I can reproduce the problem with the trivial libhello.so shared lib example from
the autobook.

% cat hello.c
#include <stdio.h>

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
% 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?

Comment 3 Jens Petersen 2001-12-10 09:08:08 UTC
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.

Comment 4 Havoc Pennington 2001-12-10 15:28:53 UTC
Right, that's the point. It should be making "nm -D" not output "hello" - here
are the libtool docs:

     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.

Comment 5 Havoc Pennington 2001-12-10 15:50:53 UTC
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.

Comment 6 Havoc Pennington 2001-12-10 15:54:26 UTC
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.

Comment 7 Jens Petersen 2001-12-11 00:40:15 UTC
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

What I was trying to hint at above is that it could be a linker  bug, no?

Any comments, Jakub?

Comment 8 Havoc Pennington 2001-12-11 00:59:28 UTC
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.

Comment 9 Jens Petersen 2001-12-11 01:36:04 UTC
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

Comment 10 Jens Petersen 2001-12-11 03:40:43 UTC
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
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


[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

Comment 11 Jens Petersen 2001-12-13 05:47:09 UTC
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.

Comment 12 Jakub Jelinek 2001-12-13 09:36:25 UTC
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.

Comment 13 Jens Petersen 2002-08-14 15:14:01 UTC
James Henstridge <james@daa.com.au> posted some patches related to this:

Comment 14 Jens Petersen 2002-08-14 15:26:25 UTC
Unfortunately two tests (mdemo-make.test and dryrun.test) fail with
applied.  Will look into this further.

Comment 15 Jens Petersen 2002-08-14 15:32:43 UTC
Btw the same goes for

Comment 16 Havoc Pennington 2002-08-14 15:56:06 UTC
(cc'ing james)

Comment 17 James Henstridge 2002-08-15 00:34:24 UTC
Both of those patches leave a .ver file in the .libs/ directory.  Might that be
the cause of the problem?

Comment 18 James Henstridge 2002-08-15 01:39:18 UTC
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).

Comment 19 Jens Petersen 2002-08-15 03:24:51 UTC
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.

Comment 20 Jens Petersen 2002-08-15 03:53:17 UTC
Cc'ing Alex too.

Comment 21 Jens Petersen 2003-05-01 14:40:47 UTC
James Henstridge's expsym patch is in libtool-1.5-1,
so hopefully this resolves the problem finally.

Note You need to log in before you can comment on or make changes to this bug.