[Bug middle-end/55308] /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale"

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2013-02-25 13:29:36 UTC ---
> --- 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.)

I'd ignore that error for now, since it is certainly not related to TLS
support.  The same goes for the apparent attempt to link libstdc++.so.6
into libgcc_s.so.1 in the Description.

> "/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'.

Good you mention which assembler is actually used, i.e. not the bundled
FreeBSD as, but current binutils gas.  Any additional patches to that?

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

The question is not if the FreeBSD/SPARC binaries are SPARC64, but if
the kernel is able to execute 32-bit binaries and 32-bit runtime libs
exist for the system.  If not, than indeed there is no point in building
a multilib-capable compiler.  I'd suggest configuring gcc with
--disable-multilib in that case.

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

It does indeed.  I've now had a look at the TLS testcase and was
originally inclined to claim that the -32 flag is there in error, but
unfortunately this is not true: assembling it with gas 2.23.1 with
either -32, -64, or no flag at all produces an object file without error
or warning.  OTOH, if I try the same with Sun as (and the corresponding
.section directive), I get an error if assembling as 64-bit code:

> as -xarch=v9 -o tls.o-64 tls.s
as: "tls.s", line 17: error: unknown "%"-symbol
as: "tls.s", line 17: error: missing '('
as: "tls.s", line 17: error: statement syntax
as: "tls.s", line 18: warning: detect global register use not covered .register
pseudo-op
as: "tls.s", line 21: warning: detect global register use not covered .register
pseudo-op

The op on line 17 is

        ld      [%l7 + %o3], %o2, %tie_ld(foo)

and indeed %tie_ld is 32-bit only.  gas just fails to diagnose that,
while as does.  I'd claim this is a bug in gas, and a proper fix of the
configure.ac statement for 64-bit-only sparc targets is a bit more
involved than just omitting the -32.  I'll leave that to the sparc
maintainers.

    Rainer