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



--- Comment #8 from N8GCBP7SHNBTI79GINADGKJPRTLOCO2A at cmx dot ietfng.org 
2013-02-23 03:13:27 UTC ---

If I do not remove the -32 from configure and do a straight build out of the

ports tree, I see this in my gcc/config.log:



configure:23478: checking assembler for thread-local storage support

configure:23491: /usr/local/bin/as   -32 --fatal-warnings -o conftest.o

conftest.s >&5

Assembler messages:

Fatal error: selected target format 'elf32-sparc-freebsd' unknown

configure:23494: $? = 1

configure: failed program was



        .section ".tdata","awT",@progbits

foo:    .long   25

        .text

        sethi   %tgd_hi22(foo), %o0



This appears to be the root cause of everything going south with the error

Anton

gave at the start of this thread, as xgcc is built without support for TLS, as

I

said in comment 2.  I am at a loss to explain the error in comment 5, except to

suggest that possibly some of the wrong lines were mutated (I did not check

carefully; the actual patch I am using is available at

https://github.com/nwf/nwf-patches/blob/master/freebsd-ports/gcc48-patch-sparc64-tls-fix

and should apply with no complaints; I simply place it in my ports tree as

/usr/ports/lang/gcc48/files/patch-sparc64-tls-fix and let the make magic do its

magic.)



"/usr/local/bin/as --version" says



GNU assembler (GNU Binutils) 2.23.1

Copyright 2012 Free Software Foundation, Inc.

This program is free software; you may redistribute it under the terms of

the GNU General Public License version 3 or later.

This program has absolutely no warranty.

This assembler was configured for a target of `sparc64-portbld-freebsd9.1'.



And unhelpfully its --target-help does indeed suggest that it knows about -32,

but even invoking just "as -32" yields the "selected target format unknown"

message above.



"/usr/local/bin/objdump -H" says, among many other things,



/usr/local/bin/objdump: supported targets: elf64-sparc-freebsd elf64-sparc

elf32-sparc a.out-sunos-big elf64-little elf64-big elf32-little elf32-big

plugin srec symbolsrec verilog tekhex binary ihex

/usr/local/bin/objdump: supported architectures: sparc sparc:sparclet

sparc:sparclite sparc:v8plus sparc:v8plusa sparc:sparclite_le sparc:v9

sparc:v9a sparc:v8plusb sparc:v9b plugin



which may reveal something: there is no elf32-sparc-freebsd on that list... and

indeed, looking inside the binutils sources, I see that there is special

handling in bfd/elf64-sparc.c for FreeBSD that is absent in bfd/elf32-sparc.c.

The story appears to be the same in the in-FreeBSD version of binutils in

/usr/src.  In fact, the only occurrence of "elf32-sparc-freebsd" at all

binutils

is in gas/config/tc-sparc.h, which seems like something of a bug in its own

right.  (Which I have filed, at

http://sourceware.org/bugzilla/show_bug.cgi?id=15178 )



That said, all the binaries on my system (which is, as far as I know,

relatively

stock FreeBSD 9-STABLE) are ELF 64, not ELF 32, and so, fundamentally, I don't

understand why configure is testing for the ability to build a 32 bit binary

rather than the assembler's default.  Possibly some systems require that;

binutils on FreeBSD on sparc appears to require its negation.



Does that help shed any light on the situation?  Anything I've overlooked?

Thanks.

--nwf;

Reply via email to