[Bug regression/39508] gcc libdecnumber 4.3.4 & 4.3.3 x86_64 linux : /usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4//libgcc.a(bid_decimal_globals.o): TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `__bid_IDEC_glbround' at 0x7 in section `.text' failed

[jason dot vas dot dias at gmail dot com]

------- 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