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

Reply via email to