Bug 56833 – glib >=2.3.4 seems to break glx?

• Status: RESOLVED INVALID
• Product: Gentoo Linux

[Description David Li 2004-07-12 14:29:18 UTC]

Any application that uses glx will spit out this error message after upgrading to glib >=2.4.3:

cannot set up thread-local storage: kernel too old for thread-local storage support

Recompling/Upgrading kernel does not fix this issue.

Forum posts about this:
http://forums.gentoo.org/viewtopic.php?t=196901
http://forums.gentoo.org/viewtopic.php?p=1336922

Reproducible: Always
Steps to Reproduce:
1. emerge sync
2. emerge -pu glib
3. emerge -u glib
4. run any application that uses glx
Actual Results:  
cannot set up thread-local storage: kernel too old for thread-local storage support

Expected Results:  
The application will not display error and start

Portage 2.0.50-r9 (default-x86-1.4, gcc-3.3.3, glibc-2.3.4.20040619-r0,
2.4.26-gentoo-r5)
=================================================================
System uname: 2.4.26-gentoo-r5 i686 Intel(R) Pentium(R) 4 Mobile CPU 2.00GHz
Gentoo Base System version 1.5.1
Autoconf: sys-devel/autoconf-2.59-r4
Automake: sys-devel/automake-1.8.5-r1
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-O3 -mcpu=pentium4 -march=pentium4 -mfpmath=sse -msse2 -mmmx
-fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop
-frerun-loop-opt -fprefetch-loop-arrays -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/ /var/qmail/alias /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /usr/X11R6/bin/startx /etc/env.d"
CXXFLAGS="-O3 -mcpu=pentium4 -march=pentium4 -mfpmath=sse -msse2 -mmmx
-fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop
-frerun-loop-opt -fprefetch-loop-arrays -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="http://gentoo.oregonstate.edu
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow X aavm acpi alsa apache2 apm avi berkdb bonobo cdr crypt cups doc dvd
encode esd foomaticdb gdbm gif gnome gphoto2 gpm gtk gtk2 gtkhtml guile imlib
java jpeg libg++ libwww mad maildir mikmod mmx motif mozilla mpeg mysql nas
ncurses nls oggvorbis opengl oss pam pcmcia pdflib perl png python quicktime
readline samba sdl slang spell sse ssl svga tcltk tcpd tetex tiff truetype usb
videosx x86 xml2 xmms xv zlib"

[Comment 1 David Li 2004-07-12 14:41:43 UTC]

Ok, I changed my CFLAGS to something nicer ("-O2 -pipe"), reemerge, and it still doesn't work.

[Comment 2 René Marten 2004-07-13 01:41:50 UTC]

hm I think its because 2.4.x kernels lack nptl support ...

I have the newest glibc installed and it also installed the linux2.6-headers
(2.6.6-r1)

No problem for me because I use 2.6.7-gentoo-r9

 $ genlop -i glibc
 * sys-libs/glibc


   Total builds: 7
   Global build time: 7 hours, 12 minutes and 48 seconds.
   Average merge time: 1 hour, 1 minute and 49 seconds.

   Info about currently installed ebuild:

   * sys-libs/glibc-2.3.4.20040619
   Install date: Mon Jul 12 23:57:55 2004
   USE="nls nptl -pic -build -erandom -hardened -makecheck -multilib -debug"


 $ glxinfo
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
...

[Comment 3 foser (RETIRED) 2004-07-13 02:25:06 UTC]

i'm sort of inclined to close this invalid because of your CFLAGS. Messing with your system is really your own problem to deal with, I just sense you are looking for problems reading your report.

The nptl story in comment #2 is probably right on track, but even then you have moved between 2.4 & 2.6 kernels in the past afaik or it still shouldn't happen. Anyway, the bottomline is that this is not a problem that would normally show on average user systems and I don't think there's much to fix here : downgrade your glibc or move to a 2.6 kernel. If you can reproduce on a clean system with sane cflags open a new report.

[Comment 4 René Marten 2004-07-13 03:17:17 UTC]

hmm I think the problem is that glibc still wants to install the 26-headers on an 2.4 system and than builds against it.
 I use a 2.6.x kernel for more then 9 months now so it isn't a problem 

[Comment 5 David Li 2004-07-13 07:38:12 UTC]

Indeed my glibc is not compiled with ntpl. I am wondering why ntpl is a USE flag to do it when it's not even in the use flag list (/usr/portage/profiles/use.desc)? Shouldn't there be some kind of mask preventing people from emerging the new one if ntpl is not in the USE flags?