With the latest gcc-4.3.4-branch and gcc-4.3.3 branches checked out as of
2008-02-26, built with "vanilla options" with binutils 2.19.51.20090224 
and glibc-2.9.90 of 2009-03-17, under Linux kernel 2.6.29-rc8, on an
originally Gentoo based system but with pretty much everything rebuilt
from latest versions with "vanilla" / GNU configure options, I get
this error under both 4.3.3 and 4.3.4 when linking a large dynamic executable,
when ALL objects are compiled with -fPIC, when GCC attempts to link
in GCC's internal "libdecnumber.a" object :

$ gcc -o $my_executable { .. @ 16MB of objects & shared libs } ... \
  -m64 -O -g -march=native -mtune=native -ggdb3
-Wl,-R,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4
/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
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4//libgcc.a(bid_decimal_globals.o):
could not read symbols: Bad value
collect2: ld returned 1 exit status

This happens with several different versions of ld(1), but NOT with gcc-4.2.3 .

( with libgcc_s.so.1 being ONLY installed under the 
  /usr/lib/gcc/$GCC_ARCH/$GCC_VERSION
  directories, so I use RPATH, which makes supporting executables
  linked with many different versions of libgcc easier 
).


GCC 4.3.3 and 4.3.4 were configured identically with :

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-languages=c,c++,treelang
--enable-targets=x86_64,i686 --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g--enable-multilib
--enable-bootstrap --enable-serial-configure --with-build-time-tools=/usr
--with-ld=/usr/bin/ld --with-as=/usr/bin/as --with-gnu-ld --with-gnu-as
--enable-threads=posix --enable-tls --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gomp --enable-mudflap --enable-libssp
--enable-system-zlib --enable-system-gettext --enable-nls
--without-included-gettext --disable-werror --enable-secureplt
--enable-libmudflap --enable-libgomp --enable-cld --enable-__cxa_atexit
--enable-clocale=gnu --with-pkgversion='Linux 2.6.29 GCC 4.3.4 JVD 2009-02-24'
Thread model: posix
gcc version 4.3.4 20090223 (prerelease) (Linux 2.6.29 GCC 4.3.3 JVD 2009-02-24)

Dozens of other executables and packages build just fine with 4.3.4 and 4.3.3 -
but for some reason this large database, X-Windows & GTK application, which 
also uses AT&T AST sfio & vmalloc, does not .

While gcc-4.2.3 was configured with:
$ /usr/x86_64-pc-linux-gnu/gcc-bin/4.2.3/gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-4.2.3/configure --prefix=/usr --with-system-zlib
--host=x86_64-pc-linux-gnu --enable-multilib --enable-threads=posix
Thread model: posix
gcc version 4.2.3

Any ideas anyone ?  

This one is driving me round the bend.

Thanks in advance!


-- 
           Summary: 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
           Product: gcc
           Version: 4.3.4
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: regression
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jason dot vas dot dias at gmail dot com
 GCC build triplet: x86_64-pc-linux-gnu gcc-4.2.3 glibc-2.9.90 binutils-
                    2.19.51.2009
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39508

Reply via email to