* [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"
2012-11-13 8:55 [Bug libstdc++/55308] New: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" mexas at bristol dot ac.uk
@ 2013-01-13 19:52 ` nwfilardo at gmail dot com
2013-01-15 12:56 ` mexas at bristol dot ac.uk
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: nwfilardo at gmail dot com @ 2013-01-13 19:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [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"
2012-11-13 8:55 [Bug libstdc++/55308] New: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" mexas at bristol dot ac.uk
2013-01-13 19:52 ` [Bug middle-end/55308] " nwfilardo at gmail dot com
@ 2013-01-15 12:56 ` mexas at bristol dot ac.uk
2013-01-15 13:27 ` mexas at bristol dot ac.uk
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: mexas at bristol dot ac.uk @ 2013-01-15 12:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308
--- Comment #2 from Anton Shterenlikht <mexas at bristol dot ac.uk> 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 movi a8, foo@TLSFUNC
3160 movi a10, 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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [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"
2012-11-13 8:55 [Bug libstdc++/55308] New: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" mexas at bristol dot ac.uk
2013-01-13 19:52 ` [Bug middle-end/55308] " nwfilardo at gmail dot com
2013-01-15 12:56 ` mexas at bristol dot ac.uk
@ 2013-01-15 13:27 ` mexas at bristol dot ac.uk
2013-01-24 2:56 ` N8GCBP7SHNBTI79GINADGKJPRTLOCO2A at cmx dot ietfng.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: mexas at bristol dot ac.uk @ 2013-01-15 13:27 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308
--- Comment #3 from Anton Shterenlikht <mexas at bristol dot ac.uk> 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"
#
^ permalink raw reply [flat|nested] 13+ messages in thread* [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"
2012-11-13 8:55 [Bug libstdc++/55308] New: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" mexas at bristol dot ac.uk
` (2 preceding siblings ...)
2013-01-15 13:27 ` mexas at bristol dot ac.uk
@ 2013-01-24 2:56 ` N8GCBP7SHNBTI79GINADGKJPRTLOCO2A at cmx dot ietfng.org
2013-01-25 9:38 ` mexas at bristol dot ac.uk
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: N8GCBP7SHNBTI79GINADGKJPRTLOCO2A at cmx dot ietfng.org @ 2013-01-24 2:56 UTC (permalink / raw)
To: gcc-bugs
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.000000000 +0000
+++ gcc/configure.ac 2013-01-16 22:08:48.151503275 +0000
@@ -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.000000000 +0000
+++ gcc/configure 2013-01-16 22:08:48.142499859 +0000
@@ -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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [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"
2012-11-13 8:55 [Bug libstdc++/55308] New: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" mexas at bristol dot ac.uk
` (3 preceding siblings ...)
2013-01-24 2:56 ` N8GCBP7SHNBTI79GINADGKJPRTLOCO2A at cmx dot ietfng.org
@ 2013-01-25 9:38 ` mexas at bristol dot ac.uk
2013-02-21 14:15 ` burnus at gcc dot gnu.org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: mexas at bristol dot ac.uk @ 2013-01-25 9:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308
--- Comment #5 from Anton Shterenlikht <mexas at bristol dot ac.uk> 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.000000000 +0000
+++ configure.ac 2013-01-25 09:28:24.000000000 +0000
@@ -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.000000000 +0000
+++ configure 2013-01-25 09:28:27.000000000 +0000
@@ -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 expansion of
macro '__N'
#define __multc3 __N(multc3)
^
../.././../gcc-4.8-20130113/libgcc/libgcc2.h:474:15: note: in expansion of
macro '__multc3'
extern TCtype __multc3 (TFtype, TFtype, TFtype, TFtype);
^
../.././../gcc-4.8-20130113/libgcc/libgcc2.c:1853:14: error: size of array
'compile_type_assert' is
negative
extern void *compile_type_assert[sizeof(INFINITY) == sizeof(MTYPE) ? 1 : -1];
^
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 '__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.c:1830:25: note: in expansion of
macro '__muldc3'
#define _CONCAT3(A,B,C) A##B##C
^
../.././../gcc-4.8-20130113/libgcc/libgcc2.c:1829:24: note: in expansion of
macro '_CONCAT3'
#define CONCAT3(A,B,C) _CONCAT3(A,B,C)
^
../.././../gcc-4.8-20130113/libgcc/libgcc2.c:1866:1: note: in expansion of
macro 'CONCAT3'
CONCAT3(__mul,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
^
gmake[3]: *** [_muldc3.o] Error 1
gmake[3]: Leaving directory
`/usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libgcc'
gmake[2]: *** [all-stage2-target-libgcc] Error 2
gmake[2]: Leaving directory `/usr/ports/lang/gcc48/work/build'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/usr/ports/lang/gcc48/work/build'
gmake: *** [bootstrap-lean] Error 2
*** [do-build] Error code 1
Stop in /usr/ports/lang/gcc48.
^ permalink raw reply [flat|nested] 13+ messages in thread* [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"
2012-11-13 8:55 [Bug libstdc++/55308] New: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" mexas at bristol dot ac.uk
` (4 preceding siblings ...)
2013-01-25 9:38 ` mexas at bristol dot ac.uk
@ 2013-02-21 14:15 ` burnus at gcc dot gnu.org
2013-02-22 15:48 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-02-21 14:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org,
| |ro at gcc dot gnu.org
--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 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 <ro@CeBiTec.Uni-Bielefeld.DE>
* 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.
...
^ permalink raw reply [flat|nested] 13+ messages in thread* [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"
2012-11-13 8:55 [Bug libstdc++/55308] New: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" mexas at bristol dot ac.uk
` (5 preceding siblings ...)
2013-02-21 14:15 ` burnus at gcc dot gnu.org
@ 2013-02-22 15:48 ` ro at CeBiTec dot Uni-Bielefeld.DE
2013-02-23 3:13 ` N8GCBP7SHNBTI79GINADGKJPRTLOCO2A at cmx dot ietfng.org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2013-02-22 15:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE <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
^ permalink raw reply [flat|nested] 13+ messages in thread* [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"
2012-11-13 8:55 [Bug libstdc++/55308] New: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" mexas at bristol dot ac.uk
` (6 preceding siblings ...)
2013-02-22 15:48 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2013-02-23 3:13 ` N8GCBP7SHNBTI79GINADGKJPRTLOCO2A at cmx dot ietfng.org
2013-02-25 13:30 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: N8GCBP7SHNBTI79GINADGKJPRTLOCO2A at cmx dot ietfng.org @ 2013-02-23 3:13 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 13+ messages in thread* [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"
2012-11-13 8:55 [Bug libstdc++/55308] New: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" mexas at bristol dot ac.uk
` (7 preceding siblings ...)
2013-02-23 3:13 ` N8GCBP7SHNBTI79GINADGKJPRTLOCO2A at cmx dot ietfng.org
@ 2013-02-25 13:30 ` ro at CeBiTec dot Uni-Bielefeld.DE
2013-02-25 14:16 ` mexas at bristol dot ac.uk
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2013-02-25 13:30 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread* [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"
2012-11-13 8:55 [Bug libstdc++/55308] New: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" mexas at bristol dot ac.uk
` (8 preceding siblings ...)
2013-02-25 13:30 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2013-02-25 14:16 ` mexas at bristol dot ac.uk
2013-04-23 14:20 ` mexas at bristol dot ac.uk
2013-06-10 8:00 ` mexas at bristol dot ac.uk
11 siblings, 0 replies; 13+ messages in thread
From: mexas at bristol dot ac.uk @ 2013-02-25 14:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308
--- Comment #10 from Anton Shterenlikht <mexas at bristol dot ac.uk> 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
^ permalink raw reply [flat|nested] 13+ messages in thread* [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"
2012-11-13 8:55 [Bug libstdc++/55308] New: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" mexas at bristol dot ac.uk
` (9 preceding siblings ...)
2013-02-25 14:16 ` mexas at bristol dot ac.uk
@ 2013-04-23 14:20 ` mexas at bristol dot ac.uk
2013-06-10 8:00 ` mexas at bristol dot ac.uk
11 siblings, 0 replies; 13+ messages in thread
From: mexas at bristol dot ac.uk @ 2013-04-23 14:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308
--- Comment #11 from Anton Shterenlikht <mexas at bristol dot ac.uk> 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=5000000 --split-size=5000000 -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
^ permalink raw reply [flat|nested] 13+ messages in thread* [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"
2012-11-13 8:55 [Bug libstdc++/55308] New: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" mexas at bristol dot ac.uk
` (10 preceding siblings ...)
2013-04-23 14:20 ` mexas at bristol dot ac.uk
@ 2013-06-10 8:00 ` mexas at bristol dot ac.uk
11 siblings, 0 replies; 13+ messages in thread
From: mexas at bristol dot ac.uk @ 2013-06-10 8:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308
Anton Shterenlikht <mexas at bristol dot ac.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #12 from Anton Shterenlikht <mexas at bristol dot ac.uk> ---
Fixed by a binutils patch in the latest version, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53964
^ permalink raw reply [flat|nested] 13+ messages in thread