When building glibc with CHOST="i386-pc-linux-gnu" and nptl, it was built with "--without-tls" and and assumed the user was using a 2.4-branch kernel. When building glibc with CHOST="i686-pc-linux-gnu" and nptl, it was built with "--with-tls" and and assumed the user was using a 2.6-branch kernel. Reproducible: Always Steps to Reproduce: 1. Set USE="nptl" 2. Set CHOST="i386-pc-linux-gnu" 3. emerge glibc 4. Look at output of configure 5. Set CHOST="i686-pc-linux-gnu" 6. emerge glibc 7. Look at output of configure Actual Results: When building glibc with CHOST="i386-pc-linux-gnu" and nptl, it was built without tls support and and assumed the user was using a 2.4-branch kernel. When building glibc with CHOST="i686-pc-linux-gnu" and nptl, it was built with tls support and and assumed the user was using a 2.6-branch kernel. Expected Results: According to discussion in http://bugs.gentoo.org/show_bug.cgi?id=88777 changing CHOST to a different subarch should change nothing other than the location of the toolchain files and not change how the toolchain itself is built.
i dont see the bug, behavior described is correct
That makes no sense whatsoever. If someone ran with CHOST="i386-pc-linux-gnu" and also ran a 2.6-kernel, glibc would be built for a 2.4-kernel because of the explicit assumption used in the configuration of glibc. Furthermore, why in the world would tls support be removed if all you did was change the CHOST? Also, if you read the bug report I posted the link to, multiple devs claimed that changing CHOST is expected to ONLY CHANGE THE LOCATION OF TOOLCHAIN FILES. They claimed that the behavior I described as a bug.
just because you're a dev doesnt make you right, all you need to do is use caps (which you've clearly demonstrated fluency in) CHOST is not purely cosmetic when it comes to glibc, it tells glibc what sort of code it is allowed to generate. so an i386-* CHOST will not produce the same glibc as if you used an i686-* CHOST since glibc knows that with i686-* it can use i686 optimizations. anyone who tells you different has not poked around glibc internals before. last i heard, nptl required i486 or better, thus nptl is disabled in the glibc ebuild for i386 CHOSTs, but i'll double check
I checked for you. You were right. glibc has not been ported to i386. https://www.redhat.com/archives/fedora-devel-list/2004-June/msg00035.html "i386 (and sparc < v9) lacks atomic instructions powerful enough for NPTL needs."
heh, i was just about to post that link, guess i need to be a bit faster next time
So the NPTL part makes perfect sense now. But why does tls-support go away when using i386?
Since this has been pretty much figured out, I'm closing it.
i believe tls support in general requires i486+, but please correct me if i'm wrong ;)
*** Bug 135203 has been marked as a duplicate of this bug. ***
*** Bug 140177 has been marked as a duplicate of this bug. ***
