# [SOLVED] GLIBC: "TLS support is required."

## SinoTech

I've wanted to re-compile my glibc but unfortunatelly the merge breaks with the following message:

```

nptl/sysdeps/i386/i686/../tls.h:65:3: error: #error "TLS support is required."

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:

[...]

```

I've got "nptl" and "nptlonly" in my USE-Flags, and the thing is I've re-compiled my toolchain (glibc, gcc, binutils) multiple times as I switched to gcc-4.X some weeks ago. So I wonder why I'm unable to recompile it now.

I've tried multiple version of glibc and also emerged different versions of binutils, but no luck yet.

I've also searched the forum and google, but nothing what helps (Even tried an "emerge -e world" which worked for another guy, but not for me  :Sad: ).

Since I'm working on that for the last 24h and have no solution yet I hope there's somebody out there which is able to help me  :Smile: 

However, here's my current "emerge --info" (For the case it's related to a wrong set USE-Flag):

```

Portage 2.0.53 (default-linux/amd64/2005.1, gcc-4.0.2, glibc-2.3.6-r1, 2.6.14-nitro2 x86_64)

=================================================================

System uname: 2.6.14-nitro2 x86_64 AMD Athlon(tm) 64 Processor 3000+

Gentoo Base System version 1.6.13

ccache version 2.3 [disabled]

dev-lang/python:     2.3.5, 2.4.2

sys-apps/sandbox:    1.2.12

sys-devel/autoconf:  2.13, 2.59-r6

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1

sys-devel/binutils:  2.16.1-r1

sys-devel/libtool:   1.5.20

virtual/os-headers:  2.6.11-r2

ACCEPT_KEYWORDS="amd64"

AUTOCLEAN="yes"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=athlon64 -O2 -pipe -msse3"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib64/mozilla/defaults/pref /usr/share/X11/xkb /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/control"

CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"

CXXFLAGS="-march=athlon64 -O2 -pipe -msse3"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig distlocks sandbox sfperms strict"

GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"

MAKEOPTS="-j2"                  

PKGDIR="/usr/portage/packages"  

PORTAGE_TMPDIR="/var/tmp"       

PORTDIR="/usr/portage"          

PORTDIR_OVERLAY="/usr/local/portage_overlays/portage_over /usr/local/portage_overlays/java_experimentel /usr/local/portage_overlays/gentoo_de"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="amd64 X alsa apache2 audiofile avi berkdb bitmap-fonts browserplugin bzip2 cdr crypt cscope cups curl divx4linux dvd dvdread eds emboss encode ethereal exif expat fam firefox foomaticdb fortran gif gimpprint glut gmp gnome gpm gtk gtk2 idn imagemagick imlib java jpeg junit lcms libwww lzw lzw-tiff mad mhash mng mozilla mp3 mpeg mysql ncurses nls nptl nptlonly nsplugin nvidia ogg oggvorbis opengl oss pam pcre pdflib perl png ppds python readline samba sdl spell ssl subversion tiff truetype truetype-fonts type1-fonts udev usb userlocales vorbis xine xml xml2 xmms xpm xv xvid zlib userland_GNU kernel_linux elibc_glibc"

Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

```

Regards,

SinoLast edited by SinoTech on Thu Jan 26, 2006 4:43 pm; edited 1 time in total

----------

## taylorpendley

i love this error because no one apparently knows how to fix it.

i have copied make.conf from ppl with SAME EXACT system as me and still get error with nptl use flag

out of about 30 different time starting over with a stage1 i manage to successfully compile once but now its been about 2 weeks of constant attempts and havent been able to compile it again.  It compiles so rarely i dont know what it is i do different to make it work.

It would be nice if someone could help me and the other guy with this, because this problem has been going on since last June. I stopped using gentoo last year because of it and now im trying again, but my attempt looks futile................

Is there much of a difference between nptl glibc and non-nptl glibc

----------

## SinoTech

I've solved my problem but unfotunatelly I can't remember all the things I've done. One of my problems was I've upgraded from x86 to amd64 and left all old files in my "/etc" directory. So there was a problem with "gcc-config" choosing the right compiler. Anyway, there were also one or two other things I've done to get glibc compiling again. If I've got some spare time I'll try to figure out what I've done (Currently at work, so I can't waste time for that in the moment).

Regards,

Sino

----------

## taylorpendley

yeah anything that you could do to help is appreciated. i think i remember before that i couldnt compile is with anything other than gcc-3.4.4 and all i have been trying is 4.0.2 and conrad 4.0.3 so i will give that a shot also.

----------

## SinoTech

One of things I've got back on top of my head is that Ive rebuilded world ("emerge -e world"). Anyway, if I get some more spare time I'll try to remember the other steps I've performed (Next time I'll post my solution directly to the thread).

BTW what's your system? if it is similiar mine, I could create binary packages of the needed stuff (glibc, binutils, gcc).

Regards,

Sino

----------

## taylorpendley

Thanks alot but i got it fixed now.  The first time I compile glibc it must be with binutils-2.16.91.0.5 and gcc-3.4.3 then i can recompile it with gcc-4.0*

binutils-2.16.1-r1 wont compile glibc and gives me the TLS Required error.............weird.............

----------

## SinoTech

Nice to hear that it works for you now. I've marked this thread as solved so people having same problem can see they'll find a solution hear.

Regards,

Sino

----------

## Dreadfull2

yeah bad thing that that version of binutils is masked right now ! this isn't quite a solution thought

----------

## spuniun

I solved this problem myself, but the solution confounds me.

At the time the "TLS support is required" error came up during glibc compile, the only compiler I had activated was for x86_64 CTARGET. By activating the i686 CTARGET with eselect, then switching back to x86_64 as the default, glibc compile worked.

Why is it that glibc is building against 32bit includes when I have an x86_64 CHOST?

----------

## reynolds531

I had this same problem yesterday, when I discovered that eselect-compiler had been masked and I removed it from my system. When trying to compile the new glibc-2.4-r4, I got the message about TLS support being needed. "gcc-config -l" showed that the correct version of gcc was selected, but the problem went away when I used "gcc-config -f" to force it to reselect that version of gcc.

----------

## EzInKy

 *reynolds531 wrote:*   

> I had this same problem yesterday, when I discovered that eselect-compiler had been masked and I removed it from my system. When trying to compile the new glibc-2.4-r4, I got the message about TLS support being needed. "gcc-config -l" showed that the correct version of gcc was selected, but the problem went away when I used "gcc-config -f" to force it to reselect that version of gcc.

 

I just ran into this very same issue and can verify your fix worked on my system as well.

----------

## phatmaxx

 *EzInKy wrote:*   

>  *reynolds531 wrote:*   I had this same problem yesterday, when I discovered that eselect-compiler had been masked and I removed it from my system. When trying to compile the new glibc-2.4-r4, I got the message about TLS support being needed. "gcc-config -l" showed that the correct version of gcc was selected, but the problem went away when I used "gcc-config -f" to force it to reselect that version of gcc. 
> 
> I just ran into this very same issue and can verify your fix worked on my system as well.

 

Same for me. Thanks for the tip.

----------

## svenn

Now a fun joke for us hardened TLS debuggers. Do you see it?

SPOILER: Today I can't see it either*

```
$ sudo emerge -avnutND world
```

```
Calculating world dependencies... done!

[ebuild   R   ]  sys-libs/glibc-2.4-r3  USE="nls nptl nptlonly -build -glibc-compat20% -glibc-omitfp -hardened (-multilib) -profile (-selinux)" 0 kB

[nomerge      ] sys-devel/gcc-4.1.1-r1  USE="doc fortran gtk nls (-altivec) -bootstrap -build -gcj (-hardened) -ip28 -ip32r10k -mudflap (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -test -vanilla"

[ebuild     U ]  sys-devel/gcc-config-1.3.13-r4 [1.3.13-r3] 0 kB

```

Yes, the fun lies in the fact that emerge will try to install glibc before gcc-config is updated. But that update is the solution to the problem, so the fix is not run because emerge stops on a failing glibc. (Unless I am missing a switch which tells emerge to "skip" to the next package not depending on the one that breaks)

```
$ sudo emerge -av sys-devel/gcc-config
```

followed by a

```
$ sudo emerge -avnutND world
```

makes bad dreams go away.

* For some reason I noticed the sequence and found it funny after having failed compiling glibc once. (I had failed more times during the days before) so I didn't restart emerge world that crucial second time which would actually have emerged gcc-config before glibc. I didn't pay attention to the fact that emerge emerges packages in reverse seuence.

-- 

Svenn

----------

## Zentoo

Good to hear !!

 It's about a week I'm working on a script to compile my toolchain and i didn't notice the problem because I started tweak my CFLAGS and LDFLAGS at same time I update my glibc   :Embarassed: . And I was looking why my toolchain build failed each time. I know now. So it's funny since i start back from really stable CFLAGS and LDFLAGS to stable optimised one, adding flags one by one, and recompile my toolchain each time. I was so surprised that the last set have been build completely since it was same configuration that failed before.

So now everything is fine but I get the same problem and it fixes by itself finally... Amazing   :Rolling Eyes: 

----------

## Rob Paxon

 *reynolds531 wrote:*   

> I had this same problem yesterday, when I discovered that eselect-compiler had been masked and I removed it from my system. When trying to compile the new glibc-2.4-r4, I got the message about TLS support being needed. "gcc-config -l" showed that the correct version of gcc was selected, but the problem went away when I used "gcc-config -f" to force it to reselect that version of gcc.

 

Thanks a million.  I was just about to post asking for help with this very issue but thanks to a quick forum search and your help found within that won't be necessary. Assuming this works, at least; it seems to me it got past the point where the error occurred already -- going by allotted time, anyhow.

----------

## drescherjm

I just had this problem on a box I am building for a virtual server. A little frustrating but it ends up after I just upgraded gcc from 3.4.4 to 4.1.2 and then switched the compiler with gcc-config I did not do a source /etc/profile so glibc-2.5 failed with this error all 10 times I tried to emerge it (trying various things from this thread)...

[EDIT]

Now after installing gcc-4.1.2 on the same box glibc-2.5 failed with the same error. So eventually after trying the same steps again like 10 times again (even the things that worked in the last pass) I downgraded gcc-config, removed eselect-compiler and used the gcc-config -f and that worked. Very frustrating....

[/EDIT]

----------

## Mgiese

i only have i686-pc-linux-gnu available in gcc-config -l, but i have recently switched to amd64, changed cflags,chost and profile, but now i cant recompile glibc (tls support error) nor gcc. any suggestions ? ah forgot to mention, i already updated my kernel THX a lOT in advance

----------

## tkmorris

I had this issue four times until I finally figured it out. The funny thing is that it had no logic, first time, 3 months, second time, 2 days, third time, 5 MINUTES...

Here, it was related to a make.conf misconfiguration. The fix was just about removing two variables, $CC and $CXX:

```
#CC="gcc-4.3.2"

#CXX="g++-4.3.2"
```

Now glibc builds gracefully!

----------

