This subject is endlessly addressed in the nvidia world, but my system is i810. I have set 'nptl nptlonly' and am building xorg-server-1.1.1-r1. Various things end up setting -DGLX_USE_TLS which results ultimately in modules not loading due to 'unable to handle TLS data' errors at load time. One problem is that Mesa-6.5.1/configs/linux-dri-x86 may contain -DGLX_USE_TLS. The other is that xorg-server-1.1.1-r1.ebuild contains $(use_enable nptl glx-tls) By removing these TLS references I was able to build a working system with dri and glx support.
I also use nptl/nptlonly and I don't see any of these issues. What exactly is the problem with TLS? Also, please post your emerge --info.
It's unclear to me why you think an NPTL system would be unable to handle TLS, since that's a prerequisite for NPTL.
perhaps it is a symptom of some other problem. I have an opteron system, an amd64 laptop, a couple of duo core systems, and a bunch of pentium M based systems. About 4 of them so far have gotten sick in the normal course of emerge based upgrading related to TLS. It first starting showing up as various applications reporting 'unable to handle TLS data'. Specifically in the GLX support for the i810 xorg driver. Removing the various --with-TLS options (some of which had to be hacked) produced working systems and a viable upgrade path. here is the output of emerge --info on one of the x86 systems: Portage 2.1.2_rc1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-gentoo-r9 i686) ================================================================= System uname: 2.6.16-gentoo-r9 i686 Genuine Intel(R) processor 1300MHz Gentoo Base System version 1.6.15 Last Sync: Sat, 28 Oct 2006 23:30:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=i686 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 2codecs X a52 aac alsa apache2 apm berkdb bitmap-fonts cli cpudetection cracklib crypt cups dlloader dri dvd dvdread eds elibc_glibc emboss encode esd faad foomaticdb fortran gdbm gif gpm gstreamer gtk gtk2 i8x0 iconv imlib input_devices_keyboard input_devices_mouse ipv6 isdnlog jpeg kernel_linux libg++ libwww mad mikmod mmx mmxext motif mp3 mpeg ncurses nls nptl nptlonly nvidia ogg opengl oss pam pcre perl png pppd python qt3 qt4 quicktime readline reflection rtc rtsp sdl session spell spl sse sse2 ssl tcpd truetype truetype-fonts type1-fonts udev usb userland_GNU video_cards_i810 video_cards_nvidia video_cards_vesa video_cards_via vorbis xml xorg xv xvmc zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Could be an issue with your glibc build. Reassigning to toolchain.
post the output of `/lib/libc.so.6`
GNU C Library development release version 2.4, by Roland McGrath et al. Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.1.1 (Gentoo 4.1.1). Compiled on a Linux 2.6.16 system on 2006-06-02. Available extensions: The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson GNU libio by Per Bothner NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Native POSIX Threads Library by Ulrich Drepper et al Support for some architectures added on, not maintained in glibc core. BIND-8.2.3-T5B Thread-local storage support included.
Maybe this will help: I can no longer emerge glibc. On the opteron I get /usr/include -D_LIBC_REENTRANT -include include/libc-symbols.h -DASSEMBLER -DGAS_SYNTAX -Wa,--noexecstack -E -x assembler-with-cpp' \ /bin/sh sysdeps/unix/make-syscalls.sh $dir || exit 1; }; \ test $dir = sysdeps/unix && break; \ done > /var/tmp/portage/sys-libs/glibc-2.4-r4/work/build-x86-x86_64-pc-linux-gnu-nptl/sysd-syscallsT In file included from nptl/sysdeps/i386/i686/tls.h:34, from include/tls.h:6, from sysdeps/unix/sysv/linux/i386/sysdep.h:30, from <stdin>:1: nptl/sysdeps/i386/i686/../tls.h:65:3: error: #error "TLS support is required." errors very early on though it does not stop. Later I get -fno-exceptions -o /var/tmp/portage/sys-libs/glibc-2.4-r4/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/initfini.s ../sysdeps/generic/initfini.c:1: error: CPU you selected does not support x86-64 instruction set ../sysdeps/generic/initfini.c:1: error: CPU you selected does not support x86-64 instruction set And in case you are wondering gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/gcc-4.1.1-r1/work/gcc-4.1.1/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --enable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.1 (Gentoo 4.1.1-r1)
do you actually mean the error said "cannot handle TLS data" ? also, why does your `emerge info` say gcc-3.4.6/glibc-2.3.6 when your libc.so.6 obviously came from gcc-4.1.1/glibc-2.4 ? are you randomly posting info from different machines here ?
In my own mind I decided to focus on the opteron system. I may have failed to mention it to anyone else. I could just be a case of drift, though I was surprised by all the different systems running into the problem at nearly the same time. The actual error text is 'cannot handle TLS data'. I first came across when glx was failing to load in xorg-server as a part of the i810 driver. It would show up in the xorg log and was on a Pentium M system and a Core Duo system. Next I saw it on an opteron system when trying to build glibc with the message '#error "TLS support is required."' I then saw it in an application I've forgotten the name of. It would report 'cannot handle TLS data' when I tried to execute the binary. Even strace and ldd -r against the binary would report the same message. I've 'emerge -e world' on a pentium M machine. I haven't gotten to trying to see if glx works, but I did remove all my hacks. The opteron and the amd64 are also emerging similarly. I'll report the results after all is recompiled. Perhaps I've just run into the gentoo drift problem. I.E. you can't upgrade forever. The occasional emerge -e world is required. I've done a few revdep-rebuilds along the way too.
So far as I can tell, my troubles may or may not be related to TLS and broken tool chains as described in http://forums.gentoo.org/viewtopic-t-421297-highlight-glibc+tls+required.html I am happy to see this bug tossed as caused by the problem discussed in that thread. Though I am not sure.
i havent really followed any of this when people hit the "no TLS support" error as it is due to some misconfiguration on their end i'd suggest you emerge latest stable binutils, rebuild latest stable gcc, make sure gcc-config is run, and then see if latest stable glibc builds
