This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Dynamic linker base version

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

There is some additional background at



Attachment: ver_test.tar.bz2
Description: testcase

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]