This is the mail archive of the libc-alpha@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] |
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
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] |