------- Comment #4 from jason dot vas dot dias at gmail dot com 2009-03-22 22:32 ------- Yes, compiling latest binutils did fix - many thanks Mr. Lu !
But please, is there any ld(1) or elfdump or elflint(1) or objdump(1) invocation you could suggest that would reliably tell me : 1. If the objects on the command line contain these disallowed relocations ? ( eg. $ if ! $CHECK_FOR_INVALID_RELOCATIONS foo.o libbar.so -Wl,--whole-archive ${GCC_BUILDDIR}/libgcc.a ; then ... fi ) ... NOTE: by default, libgcc.a does contain invalid relocations when producing a shared object; but how would one know if those relocations are like the one in the bug report which occur for some shared + executable dynamic objects and not others ? NOTE: by default, you cannot include the -Wl,--whole-archive argument on the ld(1) link line before libgcc.a is automatically included by gcc - you MUST use "-Wl,--no-whole-archive" BEFORE the default inclusion of libgcc.a, even if '-shared-libgcc' is on the gcc command line , because gcc inserts '-lgcc' many times ; if --whole-archive is is effect, many multiple inclusions result. Also, one MUST use '-shared-libgcc' when producing a -shared object on modern glibc linux! One must use libgcc_s.so.1 ! So it is very easy to trigger similar behaviour as described in this bug report when compiling -shared objects ! Wouldn't such a "verify only" mode for ld(1) then be very useful ? 2. If the objects on the command line contain invalid relocations for the requested output object type, then precisely which objects on the command line or in a .a result in their inclusion ? IE. for this bug report, precisely which entry points result in the dependency on __bid_IDEC_glbround , and how can I make certain that the __bid_IDEC_glbround.o containing object in libgcc.a actually does not contain a transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF ? -- jason dot vas dot dias at gmail dot com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |RESOLVED Resolution| |INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39508