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.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.