Dynamic linker base version

[Ian Lance Taylor <iant at google dot com>]

The glibc dynamic linker behaves unpredictably when asked to look up a
symbol in the base version.

The GNU linker manual says:

    __asm__(".symver original_foo,foo@@");

    foo@@ represents the symbol foo bound to the unspecified base
    version of the symbol.

The apparent intent is to support changing a library from having no
versions to one having versions.  The idea is to put the oldest version
of the symbol into the base version, and then to add new symbols to
later versions.  Executables which have no version for the symbol should
then presumably link against the base version.

However, because the glibc dynamic linker behaves unpredictably, this
behaviour is useless.

I have attached a test case.  The tests ver_test_12 and ver_test_13 are
identical except for the name of the function.  The function is named
't1' in ver_test_12 and 'f1' in ver_test_13.  When I run "make",
ver_test_12 fails and ver_test_13 passes.  I've gotten this result on
Ubuntu Lucid using eglibc 2.11.1 and on Fedora Core 14 using glibc 2.13.
I used the default GNU ld in both cases.

Currently the gold linker rejects this usage because the behaviour is
unpredictable.  Using gold instead of GNU ld for the test case will give
an error building ver_test_12b.so or ver_test_13b.so:
    ld: error: symbol t1 has undefined version
However, the developers of the FUSE library are protesting, saying that
the behaviour is documented in the GNU ld manual, and that it does
happen to work for them.

The unpredictable behaviour occurs because of how check_match nested
within do_lookup_x in elf/dl-lookup.c handles symbols with no versions.
The behaviour depends on the order in which the symbols are seen in the
hash table.

In order to know what the linkers should do in this case, I think we
need to understand what the glibc developers believe is the correct
behaviour here.  Is the current behaviour a bug which should be fixed in
glibc?  Or is gold correct in refusing to create a shared library like
this?

There is some additional background at

http://sourceforge.net/mailarchive/forum.php?thread_name=m3wrq48tso.fsf%40pepe.airs.com&forum_name=fuse-devel

http://sourceware.org/bugzilla/show_bug.cgi?id=12261

Thanks.

Ian

Attachment: ver_test.tar.bz2
Description: testcase