https://sourceware.org/bugzilla/show_bug.cgi?id=13521
Jason Gunthorpe <jgunthorpe at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jgunthorpe at gmail dot com
--- Comment #5 from Jason Gunthorpe <jgunthorpe at gmail dot com> ---
This is still an active problem. I just hit it when working with libsctp on
Ubuntu Vivid:
int main(int argc,const char *argv[])
{
printf("Here %p\n",&sctp_connectx);
}
$ gcc -fuse-ld=gold t.cc -lsctp
$ readelf -s a.out | grep -i sctp
7: 0000000000400520 0 FUNC GLOBAL DEFAULT UND sctp_connectx
36: 0000000000000000 0 FUNC GLOBAL DEFAULT UND sctp_connectx
$ gcc t.cc -lsctp
$ readelf -s a.out | grep -i sctp
7: 0000000000400560 0 FUNC GLOBAL DEFAULT UND sctp_connectx@VERS_3
(3)
56: 0000000000400560 0 FUNC GLOBAL DEFAULT UND
sctp_connectx@@VERS_3
The net result is the worst possible scenario - no error, no warning, and the
binary subtly doesn't work because it links to the wrong symbol.
Just like fuse and liblzma5, the author exactly followed the ld documentation
and expected this stuff to work.
I'm not sure why the behaviour of lds.so is being linked to this bug. It is a
good point that a shared library should not depend on this behaviour because it
does not work as described in ld.so. This will impact any transition plan to
introduce the symbol version. It is reasonable for gold to fail to link such
shared libraries.
However that has *NOTHING* to do with linking a new executable against a
library that uses that construct. GNU ld is not broken in this area and the
expected link result is crystal clear - gold should choose the default symbol
marked with @@, not the un-versioned one.
I have no idea how many fringe libraries are out there that followed the GNU
documentation and thus can't be linked into a executable when gold is the
linker. I think it is probably a good enough number that this warrants being
addressed in gold.
--
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
