https://sourceware.org/bugzilla/show_bug.cgi?id=24718
--- Comment #16 from Florian Weimer <fweimer at redhat dot com> --- (In reply to Carlos O'Donell from comment #15) > I can inject the flag: > > Version definition section '.gnu.version_d' contains 2 entries: > Addr: 0x00000000000003e8 Offset: 0x0003e8 Link: 4 (.dynstr) > 000000: Rev: 1 Flags: BASE Index: 1 Cnt: 1 Name: ./foo-run.so > 0x001c: Rev: 1 Flags: WEAK Index: 2 Cnt: 1 Name: FOO_1 > > And *then* we get the correct WEAK version reference: > > Version needs section '.gnu.version_r' contains 2 entries: > Addr: 0x0000000000400428 Offset: 0x000428 Link: 6 (.dynstr) > 000000: Version: 1 File: ./foo-run.so Cnt: 1 > 0x0010: Name: FOO_1 Flags: WEAK Version: 3 > 0x0020: Version: 1 File: libc.so.6 Cnt: 1 > 0x0030: Name: GLIBC_2.2.5 Flags: none Version: 2 Really? That's an odd link editor behavior for our implementation of symbol versioning. Shouldn't the WEAK version flag be inherited from the weak property of the symbol reference. > but we still fail: > > ./a.out2 > ./a.out2: ./foo-run.so: no version information available (required by > ./a.out2) > ./a.out2: relocation error: ./a.out2: symbol foo version FOO_1 not defined > in file ./foo-run.so with link time reference I think you botched your patching somehow. With a WEAK symbol version on the reference side, I get this: ./a.out2: ./foo-run.so: weak version `FOO_1' not found (required by ./a.out2) ./a.out2: relocation error: ./a.out2: symbol foo version FOO_1 not defined in file ./foo-run.so with link time reference Note the changed first message. The second part is the soname consistency check which causes us a lot of headache in glibc, e.g. the broken IFUNC-based forwarders in libpthread (bug 20188, bug 19861). I think we can remove the soname consistency check from the glibc loader without any ill effect, and then weak version references should work. Although we should not print the warning message when we encounter them, I think, like we don't do this for undefined weak symbols. -- 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
