public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/12977] New: glibc dynamic linker behaves unpredictable when using base version
@ 2011-07-09  5:33 ian at airs dot com
  2012-01-09  9:00 ` [Bug libc/12977] " jrnieder at gmail dot com
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: ian at airs dot com @ 2011-07-09  5:33 UTC (permalink / raw)
  To: glibc-bugs

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.


^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-06-28  5:56 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-09  5:33 [Bug libc/12977] New: glibc dynamic linker behaves unpredictable when using base version ian at airs dot com
2012-01-09  9:00 ` [Bug libc/12977] " jrnieder at gmail dot com
2012-02-21  2:17 ` [Bug ld.so|libdl/12977] " jsm28 at gcc dot gnu.org
2012-03-25  5:30 ` [Bug dynamic-link/12977] " devurandom at gmx dot net
2012-03-26 10:19 ` ppluzhnikov at google dot com
2012-03-30  7:28 ` naesten at gmail dot com
2012-05-13 23:58 ` jrnieder at gmail dot com
2014-06-23 19:29 ` david.heidelberger at ixit dot cz
2014-06-27 12:57 ` fweimer at redhat dot com
2014-06-28  5:56 ` naesten at gmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).