gcc-4.0.2/gcc/configure, line 13879: sh-*-* | sh[34]-*-*) ... tls_first_major=2 tls_first_minor=13 tls_as_opt=--fatal-warnings ;; note that this case doesn't consider the possibilities of sh[34]eb for big-endian architectures and so fails to set the variable tls_first_major, among others. this causes all kinds of grief further down in that script, line 13956: 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 that, since $tls_first_major is unset, there is no check for thread-local storage support in the big-endian case, even if you've configured for NPTL support. at a minimum, that case should add the pattern "sh[34]eb-*-*" and perhaps several more variations, but i don't know all of those possibilities. at the very least, i would add that pattern above to fix the case of building for big-endian and NPTL on sh3 and sh4.
Kaz, do you know if this problem fixed in 4.2/4.3/4.4?
Not fixed yet. The real problem isn't a GCC problem, though. NPTL in glibc works only with the little endian and would be broken for the big endian. I've heard no news about it. Supporting sh[34]eb here doesn't make sense ATM. Of course, I'll approve the patch to permit possible configurations if someone propose an appropriate one to gcc-patches, though I won't do it myself.
well, as you certainly know, glibc isnt the only C library on the block ...
(In reply to comment #3) > well, as you certainly know, glibc isnt the only C library on the block ... Sure. If uclibc folks, for example, have made NPTL work on sh[34]eb already and someone will propose a gcc patch, I'll be happy.
mmm, i was thinking this was common SH code rather than TLS specific. i doubt uClibc will get NPTL support faster than glibc ;).