bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gold/13521] ld.gold prefers unversioned symbol over default version


From: jgunthorpe at gmail dot com
Subject: [Bug gold/13521] ld.gold prefers unversioned symbol over default version
Date: Tue, 01 Sep 2015 23:13:13 +0000

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 address@hidden
(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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]