http://sourceware.org/bugzilla/show_bug.cgi?id=13521
Bug #: 13521 Summary: ld.gold prefers unversioned symbol over default version Product: binutils Version: 2.23 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: i...@airs.com ReportedBy: jrnie...@gmail.com CC: ccout...@google.com Classification: Unclassified Created attachment 6119 --> http://sourceware.org/bugzilla/attachment.cgi?id=6119 simple object with reference to lzma_code before linking The ld manual (section VERSION) explains how to allow multiple versions of the same function to appear in a given shared library[1]. Debian liblzma5 5.1.1alpha+20110809-3 does that. It provides two versions of the lzma_code function --- an unversioned compatibility symbol and a versioned symbol: | $ eu-readelf -s /usr/lib/x86_64-linux-gnu/liblzma.so.5.0.0 | grep lzma_code | 32: 00000000000030f0 142 FUNC GLOBAL DEFAULT 13 lzma_code | 33: 0000000000003020 202 FUNC GLOBAL DEFAULT 13 lzma_code@@XZ_5.0 When I link to the library using ld.bfd, the versioned symbol is preferred, as I'd expect[2]: | $ ld.bfd -o test.bfd test.o -llzma | ld.bfd: warning: cannot find entry symbol _start; defaulting to 0000000000400270 | $ eu-readelf -s test.bfd | grep lzma_code | 1: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF lzma_code@XZ_5.0 (2) | 17: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF lzma_code@@XZ_5.0 By contrast, ld.gold seems to prefer the unversioned symbol. | $ ld.gold -o test.gold test.o -llzma | $ eu-readelf -s test.gold | grep lzma_code | 1: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF lzma_code | 5: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF lzma_code Reproducible with binutils 2.22 and with a current snapshot of HEAD (3d38152c, 2011-12-19). Known problem? Any hints for tracking it down? [1] “The second GNU extension is to allow multiple versions of the same function to appear in a given shared library. In this way you can make an incompatible change to an interface without increasing the major version number of the shared library, while still allowing applications linked against the old interface to continue to function. “To do this, you must use multiple `.symver' directives in the source file. Here is an example: __asm__(".symver original_foo,foo@"); __asm__(".symver old_foo,foo@VERS_1.1"); __asm__(".symver old_foo1,foo@VERS_1.2"); __asm__(".symver new_foo,foo@@VERS_2.0"); “In this example, `foo@' represents the symbol `foo' bound to the unspecified base version of the symbol. The source file that contains this example would define 4 C functions: `original_foo', `old_foo', `old_foo1', and `new_foo'.” [2] “When you have multiple definitions of a given symbol, there needs to be some way to specify a default version to which external references to this symbol will be bound. You can do this with the `foo@@VERS_2.0' type of `.symver' directive. You can only declare one version of a symbol as the default in this manner; otherwise you would effectively have multiple definitions of the same symbol.” -- 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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils