The binutils manual for ld suggests using this syntax to define a symbol explicitly in base-version: __asm__(".symver original_foo,foo@"); __asm__(".symver new_foo,foo@@VERS2"); but code compiled with this syntax is rejected by gold as the version "" is undefined. I'm attaching a patch to solve the issue, which ensures that the base version is registered for the "" version. Thanks, Diego
*** Bug 12262 has been marked as a duplicate of this bug. ***
Created attachment 5138 [details] Patch to solve the problem above
Thanks for the patch. I've been troubled by this for a while, because defining a symbol in the base version doesn't reliably cause the glibc dynamic linker to select it when linking against a symbol with no version information. This thread has some more information: http://sourceforge.net/mailarchive/forum.php?thread_name=m3wrq48tso.fsf%40pepe.airs.com&forum_name=fuse-devel I'm not sure what the right choice is here.
Whether there is or not a bug in the glibc loader, is not something that should matter here, IMHO. We have a documented use case that, ELF side, works exactly as intended, and a software that tries to use the documented syntax but fails. We also have Chrom(e|ium)OS going toward a hack (creating an UNVERSIONED version to attach to those symbols) just to be able to compile it. From my point of view, the right choice on the link editor side is to emit the correct ELF file (rather than stop on a corner case), and then report/track down the issue on ld.so side to ensure that it links as intended. This avoids having nasty hacks in place for fuse, and behaves as the documentation says it should.
This seems reasonable to me. The FUSE developers are unwilling to accept our workaround patch meaning we (ChromiumOS) are currently forced to maintain a local patch or use GNU ld.
Hi Ian, Could we have an update on this? It would be nice to be able to push this patch. Thanks, Raymes
The key question here is what the glibc developers believe the correct behaviour should be. If glibc is currently acting as intended, then GNU ld should change (and fuse should change too). If glibc is in error, then gold should change to match the GNU ld behaviour. Right now, as far as I can tell, gold is protecting people from relying on unpredictable glibc behaviour.
I raised the issue on the libc-alpha mailing list: http://sourceware.org/ml/libc-alpha/2011-02/msg00154.html
No response on libc mailing list. Filed a bug report: http://sourceware.org/bugzilla/show_bug.cgi?id=12977
Fixed by PR 18703. Gold will accept the base version definition, but the issue Ian raised with glibc is still open.
.