Re: Dynamic linker base version

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

Has anybody thought about the appended issue?

I find it problematic that two nearly identical programs get different
results only because they use a different function name.  I think this
needs to get cleared up one way or another, either by fixing glibc or by
deciding that the linkers should never create this sort of program.

Ian

Ian Lance Taylor <iant@google.com> writes:

> 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