Tweaked glibc 2.4 + 2.5 + snapshot ebuilds

Message

nxsty · Post by **nxsty** » Tue Mar 07, 2006 8:58 am

nesl247 wrote:nxsty: should I rebuild world after rebuilding the toolchain? (emerge glibc && emerge glibc binutils gcc libstdc++-v3 libtool portage && emerge -e world) I need to know because of my guide.

As always, thank you for your hard work.

Edit: Appears that the file is not downloading (glibc-2.3.5-patches-2.3.tar.bz2) because it hits the cudenever.edu server and hangs there.. Maybe you need to change the SRC_URI again like in your .91 ebuild?

It shouldn't be necessary since new glibc releases are backward compatible.

The file is up on my webspace and it's set as the toolchain uri in the ebuild. Though I had that problem too. Portage for some reason tries to download from every other mirror there is before trying the one i specified in the ebuild.

PrakashP:
Have you tried disabling all patching, to see if your problem lies in gibc or the patches?

PaulBredbury · Post by **PaulBredbury** » Tue Mar 07, 2006 9:09 am

nxsty wrote:Portage for some reason tries to download from every other mirror there is before trying the one i specified in the ebuild.

Add primaryuri to the RESTRICT line in the ebuild (or nomirror). From /usr/lib/portage/pym/portage.py:

Code: Select all

if "primaryuri" in mysettings["RESTRICT"].split():
	# Use the source site first.

anih · Post by **anih** » Tue Mar 07, 2006 9:13 am

all pythons programs exit with this error. i changed link to old version from my another computer and its working fine now.
maybe "gcc4ssp" use flag could break this

nxsty · Post by **nxsty** » Tue Mar 07, 2006 10:33 am

PaulBredbury wrote:
nxsty wrote:Portage for some reason tries to download from every other mirror there is before trying the one i specified in the ebuild.
Add primaryuri to the RESTRICT line in the ebuild (or nomirror). From /usr/lib/portage/pym/portage.py:
Code: Select all
if "primaryuri" in mysettings["RESTRICT"].split():
	# Use the source site first.

Thanks for the tip! I'll add it when I update my ebuild.

PrakashP · Post by **PrakashP** » Tue Mar 07, 2006 10:41 am

nxsty wrote: PrakashP:
Have you tried disabling all patching, to see if your problem lies in gibc or the patches?

Nope, do you use patches in the snapshot which aren't in the stable one? I don't want to experiment with glibc too much, as reviving the system from broken glibc isn't always so funny.

But if you think taking out the patches should be at least not unsafer than using the patched version I can give it a try.

fredor · Post by **fredor** » Tue Mar 07, 2006 1:23 pm

With glibc-2.4 snapshot, the patch 'glibc-gentoo-libdir.patch' fails.

SteveYin · Post by **SteveYin** » Tue Mar 07, 2006 3:25 pm

today, I found the binutils version 2.16.1-r2, I can see there is a patch for bdirect, is this patch the newest bdirect patch or the same as -r1.

And, does the r2 version include the hashval and dynsort?

immudium · Post by **immudium** » Tue Mar 07, 2006 5:58 pm

PrakashP wrote:
Nope, do you use patches in the snapshot which aren't in the stable one? I don't want to experiment with glibc too much, as reviving the system from broken glibc isn't always so funny. But if you think taking out the patches should be at least not unsafer than using the patched version I can give it a try.

@PrakashP
FYI, I did try applying the malloc patch mentioned here: http://sources.redhat.com/ml/libc-alpha ... 00033.html from some dude at intel linux. It applied and built cleanly to the latest glibc. Having done that, I tried various compiling switches mentioned in the post to the sat solver, but it didn't seem to make any difference. Just thought you might be interested to know so you wouldn't waste too much time there. That is the only performance related thread I could find on the mailing list.

nxsty wrote: PrakashP:
Have you tried disabling all patching, to see if your problem lies in gibc or the patches?

@nxsty
I'm game for seeing what happens with "patching disabled". Will patching be disabled if I simply remove the patch version strings? Such as:

Code: Select all

# Gentoo patchset
#PATCH_VER="2.3"
PATCH_VER=""
#PATCH_GLIBC_VER="2.3.5"
PATCH_GLIBC_VER=""

# Extra patches (http://forums.gentoo.org/viewtopic-t-376943-start-0.html)
#EXTRA_PATCH_VER="2.0"
EXTRA_PATCH_VER=""
#EXTRA_PATCH_GLIBC_VER="2.3.91"
EXTRA_PATCH_GLIBC_VER=""

#epatch "${FILESDIR}"/2.3.90/glibc-2.3.90-propolice-guard-functions.patch
#epatch "${FILESDIR}"/2.3.5/glibc-2.3.5-frandom-detect.patch

Also, it's not just the sat solver that shows performance degradation. Run nbench built against glibc 2.3.6 and then glibc 2.4 and you'll see a similar performance drop as you do with the sat solver. Again, I don't know how big of a deal it is. I can't tell a difference in the general use of my glibc 2.4 systems, but it is a curiosity which intrigues me.

PrakashP · Post by **PrakashP** » Tue Mar 07, 2006 6:13 pm

immudium wrote: @PrakashP
FYI, I did try applying the malloc patch mentioned here: http://sources.redhat.com/ml/libc-alpha ... 00033.html from some dude at intel linux. It applied and built cleanly to the latest glibc. Having done that, I tried various compiling switches mentioned in the post to the sat solver, but it didn't seem to make any difference.

Well, I wouldn't expect any difference of this particular patch, as the poster says something about issues with threaded apps - and the soler is single-threaded.

BTW, the sat solver isn't just some synthetical bench, it is a real world (scientific) app, out of date, yes, but nevertheless a lot of solvers are based on it...

roderick · Post by **roderick** » Tue Mar 07, 2006 6:19 pm

I get this using the new 2.4 overlay:

Code: Select all

checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
configure: running configure fragment for add-on linuxthreads
configure: error: fragment must set $libc_add_on_canonical

!!! ERROR: sys-libs/glibc-2.4 failed.
Call stack:
  ebuild.sh, line 1933:   Called dyn_compile
  ebuild.sh, line 971:   Called src_compile
  glibc-2.4.ebuild, line 1306:   Called toolchain-glibc_src_compile
  glibc-2.4.ebuild, line 289:   Called glibc_do_configure 'compile'

!!! failed to configure glibc
!!! If you need support, post the topmost build error, and the call stack if relevant.

Anyone else see this and/or know how to fix? I'm using Gcc 4.02 from portage and Nxsty's binutils overlay and Glibc 2.3.6-r3 with Bdirect and Hashvals enabled.

Here's my USE info from the emerge:

Code: Select all

[ebuild     U ] sys-libs/glibc-2.4 [2.3.6-r3] USE="nls nptl userlocales -build -debug% -erandom -gcc4ssp% -glibc-compat20 -glibc-omitfp -hardened -linuxthreads-tls -nomalloccheck% -nptlonly -pic -profile" 0 kB [1]

EDIT::

Code: Select all

 *             ABI:   default
 *          CBUILD:   i686-pc-linux-gnu
 *           CHOST:   i686-pc-linux-gnu
 *         CTARGET:   i686-pc-linux-gnu
 *      CBUILD_OPT:
 *     CTARGET_OPT:
 *              CC:
 *          CFLAGS:   -march=pentium-m -pipe -O2 -DNDEBUG=1

 * Configuring GLIBC for linuxthreads with:
                --disable-dev-erandom
                --with-tls
                --without-__thread
                --enable-add-ons=linuxthreads,c_stubs,libidn
                --disable-sanity-checks
                --enable-kernel=2.4.1
                --without-selinux
                --without-cvs
                --enable-bind-now
                --build=i686-pc-linux-gnu
                --host=i686-pc-linux-gnu
                --disable-profile
                --without-gd
                --with-headers=/usr/include
                --prefix=/usr
                --mandir=/usr/share/man
                --infodir=/usr/share/info
                --libexecdir=/usr/lib/misc/glibc

Enable kernel appears to be 2.4???, it immediately fails after this "error: fragment must set $libc_add_on_canonical" trying to compile threads...

roderick · Post by **roderick** » Tue Mar 07, 2006 6:57 pm

I set nptlonly and it passes the previous point of failure....

Is there a issue with TLS/Threads support in this overlay?

6D7474 · Post by **6D7474** » Tue Mar 07, 2006 10:00 pm

roderick wrote:I set nptlonly and it passes the previous point of failure....

Is there a issue with TLS/Threads support in this overlay?

correct me if I'm wrong, but AFAIK glibc 2.4 has no linuxthreads support at all - only nptl, so nptlonly flag is probably required to build it...

cheers

nxsty · Post by **nxsty** » Tue Mar 07, 2006 10:11 pm

Linuxthreads is proably broken. I tried to fix it by using a prerelease snapshot of the ports tarball (it's removed in ports-2.4) but apperantly it doesn't wok anyway.

@immudium:
Yes that should do it.

roderick · Post by **roderick** » Tue Mar 07, 2006 10:59 pm

nxsty wrote:Linuxthreads is proably broken. I tried to fix it by using a prerelease snapshot of the ports tarball (it's removed in ports-2.4) but apperantly it doesn't wok anyway.

@immudium:
Yes that should do it.

Well, foolish me, I compiled the 2.4 overlay with ntplonly and after it installed my system puked horribly.

Code: Select all

//usr/sbin/iconvconfig: relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference

After that I couldn't do anything and rebooted.

Still hoofed...

Luckily, I had a backup of 2.3.6-r3...

I booted from my Gentoo 2005.0 dvd and manually mounted my partitions and tried to chroot in. Failed with same error above.

I then tried to untar the binary package and was able to chroot in.

Rebooted after, and it looked fine, though I now had portage still thinking 2.4 was installed. I tired to re-emerge 2.3.6-r3 from binary package and when it finished and tried to unmerge 2.4 it failed with above error again.

I booted from dvd again, and did the untar and mount and then manually rebuilt 2.3.6-r3.

Well, since I'm posting this, you can see I got the system recovered.

Did I do something wrong? Is there some requirement for a ntplonly system I missed along the way that caused glibc 2.4 to bail after install?

Thanks.

immudium · Post by **immudium** » Tue Mar 07, 2006 11:27 pm

nxsty wrote: @immudium:
Yes that should do it.

OK, thanks. I disabled patching as indicated above and rebuilt glibc and my toolchain to make sure things were clean. Sadly, nearly identical bohm sat and nbench scores as before. But, undaunted, I'll keep digging at it. I'll hit pay dirt eventually... maybe...

roderick · Post by **roderick** » Wed Mar 08, 2006 2:30 am

So, since I tried (unsuccessfully) to install with nptlonly, should I build first the existing glibc 2.3.6-r3 with nptlonly and then try to upgrade to 2.4? Could that help?

nxsty · Post by **nxsty** » Wed Mar 08, 2006 8:34 am

roderick wrote:Well, foolish me, I compiled the 2.4 overlay with ntplonly and after it installed my system puked horribly.
Code: Select all
//usr/sbin/iconvconfig: relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference

Hm.. There should be no /lib/tls after you compiled glibc with nptlonly. Perhaps that's the problem? Glibc 2.3.6 still have files in /lib/tls while glibc 2.4 has replaced everything else? And mixing glibc versions is not a good idea.

Try compiling glibc 2.3.6 with nptlonly, run revdep-rebuild and then try 2.4 again. It might work.

SimedonMyrrho · Post by **SimedonMyrrho** » Wed Mar 08, 2006 1:19 pm

Linuxthreads is proably broken. I tried to fix it by using a prerelease snapshot of the ports tarball (it's removed in ports-2.4) but apperantly it doesn't wok anyway.

I think glibc v2.4 is a good starting point to remove linuxthreads from glibc, in this overlay at least. I did that yesterday with the 2.4 ebuild.

I have to say i did first build glibc with nptlonly, but then a second time after encountering some issue with libpthread.so.0 missing, i edited the ebuild again and removed the use flags "linuxthreads-tls", "nptl" and "nptlonly", and all the logic behind it (want_nptl and friends). It worked, after some EXCLUDE_EXTRA_PATCH magic additions.

Also there is some cleaning logic for libpthread, please remember this, too, if trying the same.

Maybe a poll concerning the removal of linuxthreads should be considered.

nxsty · Post by **nxsty** » Wed Mar 08, 2006 5:52 pm

I made the ebuild die on !nptlonly. I didn't rip out the code since I might enable it again if upstream fixes it.

roderick · Post by **roderick** » Wed Mar 08, 2006 9:00 pm

nxsty wrote:
roderick wrote:Well, foolish me, I compiled the 2.4 overlay with ntplonly and after it installed my system puked horribly.
Code: Select all
//usr/sbin/iconvconfig: relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference
Hm.. There should be no /lib/tls after you compiled glibc with nptlonly. Perhaps that's the problem? Glibc 2.3.6 still have files in /lib/tls while glibc 2.4 has replaced everything else? And mixing glibc versions is not a good idea. Try compiling glibc 2.3.6 with nptlonly, run revdep-rebuild and then try 2.4 again. It might work.

Ok, I'm up for some more adventure/torture tonight. I'll rebuild Glibc 2.3.6-r3 with nptlonly and see if the /lib/tls/libc.so.6 is still there. It shouldn't, according to what you say. I'll also run a equery on the directory to make sure it really doesn't belong to any package and I'll run a revdep-rebuild.

If all goes well, I should be able to reboot with 2.3.6 in nptlonly, and no tls hanging around. If that works, I'll try to move to 2.4 again.

One question, will this break games like NWN which are provided as a binary package? I have libstdc++v3 installed...

Thanks.

immudium · Post by **immudium** » Wed Mar 08, 2006 11:06 pm

roderick wrote: One question, will this break games like NWN which are provided as a binary package? I have libstdc++v3 installed...
Thanks.

I don't know about NWN (Neverwinter Nights?) but I've never had any problems running Quake 4, Doom 3, Nero or VMWare in conjunction with nptlonly.

CoffeeBuzz · Post by **CoffeeBuzz** » Thu Mar 09, 2006 3:14 pm

Just trying out glibc2.4 with your overlay, compiling most recent Xgl I get this

if /bin/sh ../../../libtool --tag=CC --mode=compile i686-pc-linux-gnu-gcc -DHAVE
_CONFIG_H -I. -I. -I../../../include -I../../../include -I../../../include -I../
../../include -I../../../include -I../../../include -I../../../include -I../../.
./include -I/var/tmp/portage/xgl-0.0.1_alpha20060310/work/Mesa/include -I../X -I
../array_cache -I../glapi -I../main -I../math -I../shader -I../swrast -I../swras
t_setup -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include -I../.
./../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -DXGLServer -DXFree86Server -
DIN_MODULE -DXFree86Module -DXFree86LOADER -DXFree86Server -DUSE_MGL_NAMESPACE
-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declara
tions -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STI
CKY_DIR_BIT -I../../../include -I../../../include -I../../../Xext -I../../../c
omposite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I..
/../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr
-I../../../fb -O2 -march=pentium4 -fomit-frame-pointer -ftracer -pipe -MT xm_ap
i.lo -MD -MP -MF ".deps/xm_api.Tpo" -c -o xm_api.lo xm_api.c; \
then mv -f ".deps/xm_api.Tpo" ".deps/xm_api.Plo"; else rm -f ".deps/xm_api.Tpo";
exit 1; fi
In file included from /usr/include/limits.h:153,
from /usr/lib/gcc/i686-pc-linux-gnu/4.0.3-20060209/include/limits.h:122,
from /usr/lib/gcc/i686-pc-linux-gnu/4.0.3-20060209/include/syslimits.h:7,
from /usr/lib/gcc/i686-pc-linux-gnu/4.0.3-20060209/include/limits.h:11,
from ../main/glheader.h:64,
from ../main/imports.h:41,
from ../main/context.h:52,
from xf86glx.c:55:
/usr/include/bits/xopen_lim.h:95:6: error: missing binary operator before token "sizeof"
/usr/include/bits/xopen_lim.h:98:7: error: missing binary operator before token "sizeof"
/usr/include/bits/xopen_lim.h:122:6: error: missing binary operator before token "~"
In file included from /usr/include/stdlib.h:438,
from ../main/glheader.h:65,
from ../main/imports.h:41,
from ../main/context.h:52,
from xf86glx.c:55:
/usr/include/sys/types.h:62: error: conflicting types for 'xf86dev_t'
../../../hw/xfree86/os-support/xf86_libc.h:87: error: previous declaration of 'xf86dev_t' was here
/usr/include/sys/types.h:110: error: conflicting types for 'xf86ssize_t'
../../../hw/xfree86/os-support/xf86_libc.h:86: error: previous declaration of 'xf86ssize_t' was here
In file included from /usr/include/stdlib.h:438,
from ../main/glheader.h:65,
from ../main/imports.h:41,
from ../main/context.h:52,
from xf86glx.c:55:
/usr/include/sys/types.h:151: error: duplicate 'unsigned'
In file included from ../main/glheader.h:65,
from ../main/imports.h:41,
from ../main/context.h:52,
from xf86glx.c:55:

and it continues on and on. First error I've encountered, this look like xgl problem or glibc problem?

Tyler_Durden · Post by **Tyler_Durden** » Thu Mar 09, 2006 9:50 pm

CoffeeBuzz wrote:First error I've encountered, this look like xgl problem or glibc problem?

No Problems here with xgl-0.0.1_alpha20060307/today svn up of your complete overlay (except xgl didn't like my LDFLAGS, so i had to comment it out).

Code: Select all

root@HAL9000 ~ 0 3.32 # emerge --info

Portage 2.1_pre5-r4 (default-linux/amd64/2006.0, gcc-4.1.0, glibc-2.4-r0, 2.6.15-nitro3 x86_64)
=================================================================
System uname: 2.6.15-nitro3 x86_64 AMD Athlon(tm) 64 Processor 4000+
Gentoo Base System version 1.12.0_pre16
dev-lang/python:     2.3.5, 2.4.2-r1
sys-apps/sandbox:    1.2.17
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-r1
sys-devel/binutils:  2.16.91.0.6
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -O2 -pipe -msse3 -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/env.d"
CXXFLAGS="-march=k8 -O2 -pipe -msse3 -fomit-frame-pointer -ffriend-injection -fvisibility-inlines-hidden"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo"
LANG="de_DE.UTF-8"
LC_ALL="de_DE.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--enable-new-dtags -Wl,-Bdirect -Wl,--as-needed -Wl,-hashvals -Wl,-zdynsort"
LINGUAS="de"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/gnome-experimental /usr/local/overlays/xgloverlay"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="amd64 X a52 aac aalib acl acpi alsa amd apm arts artswrappersuid audiofile avi bash-completion berkdb bitmap-fonts blas bluetooth bzip2 cairo cdr crypt css cups curl dbus dga directfb dpms dri dts dvb dvd dvdnav dvdr dvdread eds emboss emul-linux-x86 encode esd exif fam fbcon fbsplash ffmpeg firefox flac font-server fontconfig foomaticdb fortran gd gif gimp gimpprint glx gnome gphoto2 gpm gs gstreamer gtk gtk2 hal icq ieee1394 imagemagick imlib ipv6 java jce jpeg kde kdeenablefinal lame lapack ldap libcaca live lm_sensors logitech-mouse logrotate lzw lzw-tiff mad mozilla mozsvg mp3 mpeg musicbrainz ncurses nls nntp nptl nptlonly nsplugin ntfs nvidia offensive ogg oggvorbis opengl pam pdf pdflib perl pertty png ppds python qt quicktime readline real risky rtc sblive scanner sdl slang smp spell ssl svg symlink tcltk tcpd threads tiff truetype truetype-fonts type1 type1-fonts udev unicode usb userlocales v4l v4l2 visualization vorbis x264 xcomposite xext xfs xine xinerama xmms xosd xpm xprint xv xvid xvmc zlib elibc_glibc input_devices_evdev input_devices_keyboard input_devices_mouse input_devices_-acecad input_devices_-aiptek input_devices_-calcomp input_devices_-citron input_devices_-digitaledge input_devices_-dmc input_devices_-dynapro input_devices_-elo2300 input_devices_-elographics input_devices_-fpit input_devices_-hyperpen input_devices_-jamstudio input_devices_-joystick input_devices_-magellan input_devices_-magictouch input_devices_-microtouch input_devices_-mutouch input_devices_-palmax input_devices_-penmount input_devices_-spaceorb input_devices_-summa input_devices_-synaptics input_devices_-tek4957 input_devices_-ur98 input_devices_-vmmouse input_devices_-void kernel_linux linguas_de userland_GNU video_cards_nvidia video_cards_-apm video_cards_-ark video_cards_-ati video_cards_-chips video_cards_-cirrus video_cards_-cyrix video_cards_-dummy video_cards_-fbdev video_cards_-fglrx video_cards_-glint video_cards_-i128 video_cards_-i740 video_cards_-i810 video_cards_-imstt video_cards_-mga video_cards_-neomagic video_cards_-newport video_cards_-nsc video_cards_nv video_cards_-rendition video_cards_-s3 video_cards_-s3virge video_cards_-savage video_cards_-siliconmotion video_cards_-sis video_cards_-sisusb video_cards_-sunbw2 video_cards_-suncg14 video_cards_-suncg3 video_cards_-suncg6 video_cards_-sunffb video_cards_-sunleo video_cards_-suntcx video_cards_-tdfx video_cards_-tga video_cards_-trident video_cards_-tseng video_cards_v4l video_cards_vesa video_cards_vga video_cards_-via video_cards_-vmware video_cards_-voodoo"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS

CoffeeBuzz · Post by **CoffeeBuzz** » Thu Mar 09, 2006 11:50 pm

yeah, the Xorg people fixed the error. A-ok now (well, xgl deosnt work quite right but thats another story)

epstevns40 · Post by **epstevns40** » Fri Mar 10, 2006 2:25 am

roderick wrote:So, since I tried (unsuccessfully) to install with nptlonly, should I build first the existing glibc 2.3.6-r3 with nptlonly and then try to upgrade to 2.4? Could that help?

I had glibc 4 fail during the configure stating that I needed to enable nptl and nptlonly use flags. These were clearly set in my make.conf, however, the the flags would not set on the emerge line. Doing a little digging in /usr/portage/profiles/default-linux/x86/2006.0/make.defaults the default make config line showed -nptl as the default. This was clobbering the /etc/make.conf USE flags and subsequently clobbering the glibc-2.4 ebuild.
I changed the -nptl to nptl in the default make profile and the glibc 2.4 ebuild compiled the way I have become accustomed- in other words-- very nicely

Should the "-nptl" in the 2006.0 profile be there for a reason or could this be a bug?
Hope this helps!