This is the mail archive of the glibc-bugs@sourceware.org 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]

[Bug libc/12977] New: glibc dynamic linker behaves unpredictable when using base version


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

           Summary: glibc dynamic linker behaves unpredictable when using
                    base version
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: ian@airs.com


Created attachment 5840
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5840
Test case

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

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


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