[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"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308 Anton Shterenlikht changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Anton Shterenlikht --- Fixed by a binutils patch in the latest version, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53964
[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"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308 --- Comment #11 from Anton Shterenlikht 2013-04-23 14:20:11 UTC --- The same error on the same sparc64/FreeBSD -current system building 4.9: gmake[5]: Leaving directory `/usr/ports/lang/gcc49/work/build/sparc64-portbld-freebsd10.0/libgomp/testsuite' gmake[5]: Entering directory `/usr/ports/lang/gcc49/work/build/sparc64-portbld-freebsd10.0/libgomp' makeinfo --no-split --split-size=500 --split-size=500 -I ../.././../gcc-4.9-20130414/libgomp/../gcc/doc/include -I ../.././../gcc-4.9-20130414/libgomp -o libgomp.info ../.././../gcc-4.9-20130414/libgomp/libgomp.texi /bin/sh ./libtool --tag=CC --mode=compile /usr/ports/lang/gcc49/work/build/./gcc/xgcc -B/usr/ports/lang/gcc49/work/build/./gcc/ -B/usr/local/sparc64-portbld-freebsd10.0/bin/ -B/usr/local/sparc64-portbld-freebsd10.0/lib/ -isystem /usr/local/sparc64-portbld-freebsd10.0/include -isystem /usr/local/sparc64-portbld-freebsd10.0/sys-include-DHAVE_CONFIG_H -I. -I../.././../gcc-4.9-20130414/libgomp -I../.././../gcc-4.9-20130414/libgomp/config/posix -I../.././../gcc-4.9-20130414/libgomp -Wall -Werror -Wc,-pthread -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c -o alloc.lo ../.././../gcc-4.9-20130414/libgomp/alloc.c libtool: compile: /usr/ports/lang/gcc49/work/build/./gcc/xgcc -B/usr/ports/lang/gcc49/work/build/./gcc/ -B/usr/local/sparc64-portbld-freebsd10.0/bin/ -B/usr/local/sparc64-portbld-freebsd10.0/lib/ -isystem /usr/local/sparc64-portbld-freebsd10.0/include -isystem /usr/local/sparc64-portbld-freebsd10.0/sys-include -DHAVE_CONFIG_H -I. -I../.././../gcc-4.9-20130414/libgomp -I../.././../gcc-4.9-20130414/libgomp/config/posix -I../.././../gcc-4.9-20130414/libgomp -Wall -pthread -Werror -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c ../.././../gcc-4.9-20130414/libgomp/alloc.c -fPIC -DPIC -o .libs/alloc.o /usr/ports/lang/gcc49/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" gmake[5]: *** [alloc.lo] Error 1 gmake[5]: Leaving directory `/usr/ports/lang/gcc49/work/build/sparc64-portbld-freebsd10.0/libgomp' gmake[4]: *** [all-recursive] Error 1
[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"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308 --- Comment #10 from Anton Shterenlikht 2013-02-25 14:15:32 UTC --- Just to say that on my system I have the same GAS version: # /usr/local/bin/as --version 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-freebsd10.0'. Also, I see these assembler related errors in gcc/config.log (the full log: http://seis.bris.ac.uk/~mexas/sparc64-gcc48-config.log) configure:21795: /usr/local/bin/as-o conftest.o conftest.s >&5 conftest.s: Assembler messages: conftest.s:1: Error: unknown pseudo-op: `.literal16' configure:21934: checking assembler for .nsubspa comdat configure:21948: /usr/local/bin/as-o conftest.o conftest.s >&5 conftest.s: Assembler messages: conftest.s:2: Error: unknown pseudo-op: `.nsubspa' configure:25960: checking assembler for buggy dwarf2 .file directive configure:25970: /usr/local/bin/as-o conftest.o conftest.s >&5 conftest.s: Assembler messages: conftest.s:2: Error: file number 1 already allocated configure:26114: checking assembler for .lcomm with alignment configure:26123: /usr/local/bin/as-o conftest.o conftest.s >&5 conftest.s: Assembler messages: conftest.s:1: Error: junk at end of line, first unrecognized character is `,' configure:26153: checking assembler for gnu_unique_object configure:26167: /usr/local/bin/as-o conftest.o conftest.s >&5 conftest.s: Assembler messages: conftest.s:1: Error: symbol type "gnu_unique_object" is supported only by GNU targets
[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"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308
--- Comment #9 from 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
[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"
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;
[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"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-02-22 15:48:00 UTC --- There seems to be something totally confused here: when linking libgcc_s.so, there's a reference to libstdc++.so: [...] lc && rm -f /libgcc_s.so && if [ -f /libgcc_s.so.1 ]; then mv -f /libgcc_s.so.1 /libgcc_s.so.1.backup; else true; fi && mv /libgcc_s.so.1.tmp /libgcc_s.so.1 && ln -s libgcc_s.so.1 /libgcc_s.so /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" gmake[3]: *** [libgcc_s.so] Error 1 This cannot be right, at least this won't happen during a regular gcc build. You first need to find out which object/shared object references this undefined symbol. Only after this analysis is done, we can come to further conclusions. If you have already done the analysis, you should include the results in the PR. Apart from that, tls_as_opt="-32 --fatal-warnings" is in the non-Solaris gas sections of configure.ac and has been there even before my patch to improve Solaris/SPARC TLS support. What assembler does this build use? I suppose it is some version of gas, in which case I've got a hard time believing that it doesn't support -32. If this is a completely different assembler, you'll have to add support for the options it does and doesn't understand, and perhaps even more to properly enable native TLS. Rainer
[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"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||ro at gcc dot gnu.org --- Comment #6 from Tobias Burnus 2013-02-21 14:15:07 UTC --- Comment 1 states: > This appears to be due to r162478; in particular, gcc/configure.ac:3163 is > >tls_as_opt="-32 --fatal-warnings", which may be correct for > Solaris, > but is certainly wrong on freebsd portbld (where binutils does not support > elf32-sparc-freebsd). That's the following pretty old commit (4.6 trunk): http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162478 2010-07-23 Rainer Orth * configure.ac: Don't disable TLS on Solaris 8/9 by default Set tga_func for Solaris 2/x86 resp. SPARC. Remove duplicate parts of sparc*-sun-solaris2.* TLS check. (LIB_THREAD_LDFLAGS_SPEC): Define. (LIB_TLS_SPEC): Define. ...
[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"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308 --- Comment #5 from Anton Shterenlikht 2013-01-25 09:37:38 UTC --- I'm building gcc-4.8-20130113. I tried your patch, although my line numbers are different: # diff -u10 configure.ac.orig configure.ac --- configure.ac.orig 2013-01-11 11:46:21.0 + +++ configure.ac2013-01-25 09:28:24.0 + @@ -3153,21 +3153,21 @@ if test x$on_solaris = xyes && test x$gas_flag = xno; then conftest_s=' .section ".tdata",#alloc,#write,#tls' tls_first_major=0 tls_first_minor=0 else conftest_s=' .section ".tdata","awT",@progbits' tls_first_major=2 tls_first_minor=14 - tls_as_opt="-32 --fatal-warnings" + tls_as_opt="--fatal-warnings" fi conftest_s="$conftest_s foo: .long 25 .text sethi %tgd_hi22(foo), %o0 add %o0, %tgd_lo10(foo), %o1 add %l7, %o1, %o0, %tgd_add(foo) call__tls_get_addr, %tgd_call(foo) sethi %tldm_hi22(foo), %l1 add %l1, %tldm_lo10(foo), %l2 # # diff -u10 configure.orig configure --- configure.orig 2013-01-11 11:46:21.0 + +++ configure 2013-01-25 09:28:27.0 + @@ -23390,21 +23390,21 @@ if test x$on_solaris = xyes && test x$gas_flag = xno; then conftest_s=' .section ".tdata",#alloc,#write,#tls' tls_first_major=0 tls_first_minor=0 else conftest_s=' .section ".tdata","awT",@progbits' tls_first_major=2 tls_first_minor=14 - tls_as_opt="-32 --fatal-warnings" + tls_as_opt="--fatal-warnings" fi conftest_s="$conftest_s foo: .long 25 .text sethi %tgd_hi22(foo), %o0 add %o0, %tgd_lo10(foo), %o1 add %l7, %o1, %o0, %tgd_add(foo) call__tls_get_addr, %tgd_call(foo) sethi %tldm_hi22(foo), %l1 add %l1, %tldm_lo10(foo), %l2 # I then get this failure: gmake[4]: Leaving directory `/usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libgcc' /usr/ports/lang/gcc48/work/build/./gcc/xgcc -B/usr/ports/lang/gcc48/work/build/./gcc/ -B/usr/local/ sparc64-portbld-freebsd10.0/bin/ -B/usr/local/sparc64-portbld-freebsd10.0/lib/ -isystem /usr/local/ sparc64-portbld-freebsd10.0/include -isystem /usr/local/sparc64-portbld-freebsd10.0/sys-include -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing -O2 -g -O2 -pipe -I/usr/local/include -fno- strict-aliasing -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pthread -g -DIN_LIBGCC2 -f building-libgcc -fno-stack-protector -fPIC -pthread -I. -I. -I../.././gcc -I../.././../gcc-4.8-20 130113/libgcc -I../.././../gcc-4.8-20130113/libgcc/. -I../.././../gcc-4.8-20130113/libgcc/../gcc -I ../.././../gcc-4.8-20130113/libgcc/../include -DHAVE_CC_TLS -o _muldc3.o -MT _muldc3.o -MD -MP -M F _muldc3.dep -DL_muldc3 -c ../.././../gcc-4.8-20130113/libgcc/libgcc2.c -fvisibility=hidden -DHIDE _EXPORTS In file included from ../.././../gcc-4.8-20130113/libgcc/libgcc2.c:58:0: ../.././../gcc-4.8-20130113/libgcc/libgcc2.h:254:16: warning: conflicting types for built-in functi on '__divdc3' [enabled by default] #define __N(a) __ ## a ^ ../.././../gcc-4.8-20130113/libgcc/libgcc2.h:363:19: note: in expansion of macro '__N' #define __divdc3 __N(divdc3) ^ ../.././../gcc-4.8-20130113/libgcc/libgcc2.h:452:15: note: in expansion of macro '__divdc3' extern DCtype __divdc3 (DFtype, DFtype, DFtype, DFtype); ^ ../.././../gcc-4.8-20130113/libgcc/libgcc2.h:254:16: warning: conflicting types for built-in functi on '__muldc3' [enabled by default] #define __N(a) __ ## a ^ ../.././../gcc-4.8-20130113/libgcc/libgcc2.h:351:19: note: in expansion of macro '__N' #define __muldc3 __N(muldc3) ^ ../.././../gcc-4.8-20130113/libgcc/libgcc2.h:453:15: note: in expansion of macro '__muldc3' extern DCtype __muldc3 (DFtype, DFtype, DFtype, DFtype); ^ ../.././../gcc-4.8-20130113/libgcc/libgcc2.h:254:16: warning: conflicting types for built-in functi on '__divtc3' [enabled by default] #define __N(a) __ ## a ^ ../.././../gcc-4.8-20130113/libgcc/libgcc2.h:369:19: note: in expansion of macro '__N' #define __divtc3 __N(divtc3) ../.././../gcc-4.8-20130113/libgcc/libgcc2.h:473:15: note: in expansion of macro '__divtc3' extern TCtype __divtc3 (TFtype, TFtype, TFtype, TFtype); ^ ../.././../gcc-4.8-20130113/libgcc/libgcc2.h:254:16: warning: conflicting types for built-in functi on '__multc3' [enabled by default] #define __N(a) __ ## a ^ ../.././../gcc-4.8-20130113/libgcc/libgcc2.h:357:19: note: in ex
[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"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308 --- Comment #4 from N8GCBP7SHNBTI79GINADGKJPRTLOCO2A at cmx dot ietfng.org 2013-01-24 02:56:14 UTC --- I'm not proposing changing all of them. The one (two) that are significant to my case are these: --- gcc/configure.ac.orig 2013-01-02 11:57:31.0 + +++ gcc/configure.ac2013-01-16 22:08:48.151503275 + @@ -3134,21 +3134,21 @@ if test x$on_solaris = xyes && test x$gas_flag = xno; then conftest_s=' .section ".tdata",#alloc,#write,#tls' tls_first_major=0 tls_first_minor=0 else conftest_s=' .section ".tdata","awT",@progbits' tls_first_major=2 tls_first_minor=14 - tls_as_opt="-32 --fatal-warnings" + tls_as_opt="--fatal-warnings" fi conftest_s="$conftest_s foo: .long 25 .text sethi %tgd_hi22(foo), %o0 add %o0, %tgd_lo10(foo), %o1 add %l7, %o1, %o0, %tgd_add(foo) call__tls_get_addr, %tgd_call(foo) sethi %tldm_hi22(foo), %l1 add %l1, %tldm_lo10(foo), %l2 --- gcc/configure.orig 2013-01-02 11:57:31.0 + +++ gcc/configure 2013-01-16 22:08:48.142499859 + @@ -23369,21 +23369,21 @@ if test x$on_solaris = xyes && test x$gas_flag = xno; then conftest_s=' .section ".tdata",#alloc,#write,#tls' tls_first_major=0 tls_first_minor=0 else conftest_s=' .section ".tdata","awT",@progbits' tls_first_major=2 tls_first_minor=14 - tls_as_opt="-32 --fatal-warnings" + tls_as_opt="--fatal-warnings" fi conftest_s="$conftest_s foo: .long 25 .text sethi %tgd_hi22(foo), %o0 add %o0, %tgd_lo10(foo), %o1 add %l7, %o1, %o0, %tgd_add(foo) call__tls_get_addr, %tgd_call(foo) sethi %tldm_hi22(foo), %l1 add %l1, %tldm_lo10(foo), %l2 but I do not claim that the above patch is anything other than a workaround! On sparc machines that are not FreeBSD, the -32 may be necessary, I don't know.
[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"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308 --- Comment #3 from Anton Shterenlikht 2013-01-15 13:26:17 UTC --- In the latest version the line numbers are different again. # pr -n /usr/ports/lang/gcc48/work/gcc-4.8-20130106/gcc/configure.ac | grep "\-32 \-\-fatal" 2982 tls_as_opt='-32 --fatal-warnings' 3144 tls_as_opt="-32 --fatal-warnings" # pr -n /usr/ports/lang/gcc48/work/gcc-4.8-20130106/gcc/configure | grep "\-32 \-\-fatal" 23217 tls_as_opt='-32 --fatal-warnings' 23379 tls_as_opt="-32 --fatal-warnings" #
[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"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308 --- Comment #2 from Anton Shterenlikht 2013-01-15 12:56:28 UTC --- I get a different line at 3163: # pr -n /usr/ports/lang/gcc48/work/gcc-4.8-20121014/gcc/configure.ac | grep -C5 3163 3158 .text 3159 movia8, foo@TLSFUNC 3160 movia10, foo@TLSARG 3161 callx8.tls a8, foo@TLSCALL' 3162 tls_first_major=2 3163 tls_first_minor=19 3164 ;; 3165 changequote([,])dnl 3166 esac 3167 set_have_as_tls=no 3168 if test "x$enable_tls" = xno ; then # and I see "-32" in these lines: # pr -n /usr/ports/lang/gcc48/work/gcc-4.8-20121014/gcc/configure.ac | grep "\-32" 2950 tls_as_opt='-32 --fatal-warnings' 3099 tls_as_opt="-32 --fatal-warnings" # and # pr -n /usr/ports/lang/gcc48/work/gcc-4.8-20121014/gcc/configure | grep "\-32 \-\-fatal" 23174 tls_as_opt='-32 --fatal-warnings' 23323 tls_as_opt="-32 --fatal-warnings" # Are you suggesting removing all those? These files are too complicated for me to analyse.
[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"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308 nwfilardo at gmail dot com changed: What|Removed |Added CC||nwfilardo at gmail dot com --- Comment #1 from nwfilardo at gmail dot com 2013-01-13 19:51:53 UTC --- This appears to be due to r162478; in particular, gcc/configure.ac:3163 is tls_as_opt="-32 --fatal-warnings", which may be correct for Solaris, but is certainly wrong on freebsd portbld (where binutils does not support elf32-sparc-freebsd). As a result of this mistaken argument to as, the configuration system does not believe that the machine supports TLS and so builds an xgcc that does not support it, which yields (after much CPU time) the reported error message. Removing the "-32" from gcc/configure.ac (and gcc/configure) does the right thing for me on my freebsd box, but I won't claim that it's the right fix in general -- it should probably be conditional either on not-freebsd or just-solaris.
