This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/12977] New: glibc dynamic linker behaves unpredictable when using base version
- From: "ian at airs dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Sat, 9 Jul 2011 05:33:04 +0000
- Subject: [Bug libc/12977] New: glibc dynamic linker behaves unpredictable when using base version
- Auto-submitted: auto-generated
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.