The above ebuild entered an infinite loop during compile when compiled with USE="nptl". Also, The ebuild seems to be referencing my kernel source tree in /lib/modules/2.6.2-gentoo/build/include directory which is also quite incorrect. The ebuild is infinite looping at: make[1]: Entering directory `/var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2' make[1]: Warning: File `/lib/modules/2.6.2-gentoo/build/include/linux/limits.h' has modification time 4.3e+04 s in the future rm -f /var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2/buildhere/tls.makeT /var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2/buildhere/tls.mak e.dT (echo '# Generated from tls.make.c by Makerules.'; \ gcc -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -freorder-blocks -march=athlon-xp -mpreferred-stack-boundary=2 -Iinclude -I. -I/var/ tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2/buildhere -Ilibio -Inptl -I/var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2/buildhere -Isysdeps/ i386/elf -Inptl/sysdeps/unix/sysv/linux/i386/i686 -Inptl/sysdeps/unix/sysv/linux/i386 -Inptl/sysdeps/unix/sysv/linux -Inptl/sysdeps/pthread -Isysdeps/pthread - Inptl/sysdeps/unix/sysv -Inptl/sysdeps/unix -Inptl/sysdeps/i386/i686 -Inptl/sysdeps/i386 -Isysdeps/unix/sysv/linux/i386 -Isysdeps/unix/sysv/linux -Isysdeps/gnu -Isysdeps/unix/common -Isysdeps/unix/mman -Isysdeps/unix/inet -Isysdeps/unix/sysv/i386 -Isysdeps/unix/sysv -Isysdeps/unix/i386 -Isysdeps/unix -Isysdeps/posix -Isysdeps/i386/i686/fpu -Isysdeps/i386/i686 -Isysdeps/i386/i486 -Inptl/sysdeps/i386/i486 -Isysdeps/i386/fpu -Isysdeps/i386 -Isysdeps/wordsize-32 -Isysdeps/ieee 754/ldbl-96 -Isysdeps/ieee754/dbl-64 -Isysdeps/ieee754/flt-32 -Isysdeps/ieee754 -Isysdeps/generic/elf -Isysdeps/generic -nostdinc -isystem /usr/lib/gcc-lib/i68 6-pc-linux-gnu/3.3.2/include -isystem /lib/modules/2.6.2-gentoo/build/include -D_LIBC_REENTRANT -D_LIBC_REENTRANT -include include/libc-symbols.h -E tls. make.c \ -MD -MP -MT '$(common-objpfx)tls.make' -MF /var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2/buildhere/tls.make.dT \ | sed -n '/@@@/{s/@@@[ ]*\(.*\)@@@/\1/;s/[ ]*$//p;}'; \ echo 'common-generated += tls.make'; \ sed -e 's@ /var/tmp/portage/glibc-2\.3\.3_pre20040117/work/glibc-2\.3\.2/buildhere/@ $(common-objpfx)@g' -e 's@^/var/tmp/portage/glibc-2\.3\.3_pre20040117/wor k/glibc-2\.3\.2/buildhere/@$(common-objpfx)@g' -e 's@ *\([^ \/$][^ \]*\)@ $(..)\1@g' -e 's@^\([^ \/$][^ \]*\)@$(..)\1@g' /var/tmp/portage/glibc-2.3.3_p re20040117/work/glibc-2.3.2/buildhere/tls.make.dT; \ rm -f /var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2/buildhere/tls.make.dT) > /var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2/buildhere/t ls.makeT mv -f /var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2/buildhere/tls.makeT /var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2/buildhere/tls.mak e make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2' This text repeats ad infinitum. It may be due to the limits.h file in my kernel includes having a datestamp in the future (I didn't set the clock until *after* I built the kernel), but it seems that glibc should definitely not be even looking at these headers.
when you say kernel headers do you mean /usr/include/{linux,asm} ? glibc uses those to build /usr/include/sys and stuff, so broken timestamps on that may be your bug ... ive seen infinite configure loops because of broken timestamps before ...
Touching my /usr/src/linux source tree (find /usr/src/linux -exec touch {} \;} allowed glibc-2.3.3_pre20040117 to compile properly. Why isn't this glibc depending on sys-kernel/linux-headers-2.6.x rather than its current behavior of hunting for a live kernel source tree with nptl?
Actually it should: -- # Things should be pretty stable kernel side now, so try # /usr/include first, then the current kernel's headers. headers="${ROOT}/usr/include \ /lib/modules/`uname -r`/build/include \ ${ROOT}/lib/modules/`uname -r`/build/include \ /usr/src/linux/include \ ${ROOT}/usr/src/linux/include" -- Are you sure you had 2.6 headers installed?
hi Daniel, is this still open? thanks, Alex
No response on this bug for some time, original problem is apparently fixed -- closing
