This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
(wild guess on my part, so i'm open to comments.) gcc-4.0.2/gcc/configure: ... if test -z "$tls_first_major"; then : # If we don't have a check, assume no support. else echo "$as_me:$LINENO: checking assembler for thread-local storage support" >&5 echo $ECHO_N "checking assembler for thread-local storage support... $ECHO_C" >&6 ... note how the sh3eb build doesn't even *check* for thread-local storage support, so it's clear that $tls_first_major is null. and why is it null? look a bit further up the configure script: # Thread-local storage - the check is heavily parametrized. conftest_s= tls_first_major= tls_first_minor= tls_as_opt= case "$target" in ... sh-*-* | sh[34]-*-*) conftest_s=' .section ".tdata","awT",@progbits foo: .long 25 .text .long foo@TLSGD .long foo@TLSLDM .long foo@DTPOFF .long foo@GOTTPOFF .long foo@TPOFF' tls_first_major=2 tls_first_minor=13 tls_as_opt=--fatal-warnings ;; uh huh. that case pattern doesn't accept a big-endian target pattern of sh3eb or sh4eb, does it? thoughts? is this an actual problem that should be bugzilla'ed? rday ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |