On 4/21/06, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > On Thu, 20 Apr 2006, Christian Joensson wrote: > >> /usr/bin/ld: .libs/barrier.o: check_relocs: unhandled reloc type 0 > >> .libs/barrier.o: could not read symbols: File format not recognized > >> collect2: ld returned 1 exit status > >> > >> I will restart a build and see if I get to the same error, but, if you > >> have any > > well, same thing still with Wed Apr 19 05:58:45 UTC 2006 (revision > > 113068), however, this may very well be a linker/assembler/binutils > > issue so I built, installed and used current binutils cvs trunk, Wed > > Apr 19 19:37:45 UTC 2006, 2.17.50 20060419, and tried the link command > > again. Behold, a problem with binutils it was... sorry for the noise. > > This may be related to > > [4.2 Regression] libgomp incorrectly detects support for TLS > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25865 > > and also > > libgomp bootstrap failure: unhandled reloc type 67 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27179 > > which seem to be configure problems with libgomp. I hope one of the > libgomp or configure gurus will be able to look into these soon. Right > now, several platforms fail to boostrap.
hmm, I am uncertain again. The testresults available at http://gcc.gnu.org/ml/gcc-testresults/2006-04/msg01133.html indicate that this is indeed a TLS problem. From the log file of the libgomp testsuite (with the -m64 switch), I see this, e.g.: Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ /usr/local/src/trunk/gcc/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c -B/usr/local/src/trunk/objdir/sparc64-unknown-linux-gnu/64/libgomp/ -I/usr/local/src/trunk/objdir/sparc64-unknown-linux-gnu/64/libgomp -I/usr/local/src/trunk/gcc/libgomp/testsuite/.. -mcpu=v9 -fmessage-length=0 -fopenmp -O2 -fopenmp -L/usr/local/src/trunk/objdir/sparc64-unknown-linux-gnu/64/libgomp/.libs -lgomp -lm -m64 -o ./a.15.1.exe (timeout = 1800) PASS: libgomp.c/appendix-a/a.15.1.c (test for excess errors) Setting LD_LIBRARY_PATH to .:/usr/local/src/trunk/objdir/sparc64-unknown-linux-gnu/64/libgomp/.libs:/usr/local/src/trunk/objdir/gcc:/usr/local/src/trunk/objdir/gcc/64:.:/usr/local/src/trunk/objdir/sparc64-unknown-linux-gnu/64/libgomp/.libs:/usr/local/src/trunk/objdir/gcc:/usr/local/src/trunk/objdir/gcc/64:/usr/local/src/trunk/objdir/sparc64-unknown-linux-gnu/libmudflap/.libs:/usr/local/src/trunk/objdir/sparc64-unknown-linux-gnu/libssp/.libs:/usr/local/src/trunk/objdir/sparc64-unknown-linux-gnu/libgomp/.libs:/usr/local/src/trunk/objdir/./gcc:/usr/local/src/trunk/objdir/./prev-gcc ./a.15.1.exe: error while loading shared libraries: libgomp.so.1: cannot handle TLS data FAIL: libgomp.c/appendix-a/a.15.1.c execution test and I have this: file .libs/libgomp.so.1.0.0 .libs/libgomp.so.1.0.0: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped Now, where is the TLS data supposed to be handled? Is that in glibc or somewhere else? -- Cheers, /ChJ