Running "ROOT=/some/dir emerge system" fails with: checking for i386 TLS support... yes running configure fragment for sysdeps/pthread running configure fragment for libidn/sysdeps/unix running configure fragment for sysdeps/unix/sysv/linux checking for egrep... (cached) grep -E checking installed Linux kernel header files... TOO OLD! configure: error: GNU libc requires kernel header files from Linux 2.0.10 or later to be installed before configuring. The kernel header files are found usually in /usr/include/asm and /usr/include/linux; make sure these directories use files from Linux 2.0.10 or later. This check uses <linux/version.h>, so make sure that file was built correctly when installing the kernel header files. To use kernel headers not from /usr/include/linux, use the configure option --with-headers. !!! ERROR: sys-libs/glibc-2.3.5-r2 failed. !!! Function glibc_do_configure, Line 927, Exitcode 1 !!! failed to configure glibc !!! If you need support, post the topmost build error, NOT this status message. --- The wierd thing is that glibc's ebuild (glibc-2.3.5-r2) depends on virtual/os-headers. However portage does not emerge linux-headers before emerging glibc. Reproducible: Always Steps to Reproduce:
emerge --info: Portage 2.0.51.22-r3 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14-gentoo-r2 x86_64) ================================================================= System uname: 2.6.14-gentoo-r2 x86_64 AMD Opteron(tm) Processor 242 Gentoo Base System version 1.6.13 dev-lang/python: 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 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="-O2 -march=opteron -mtune=opteron" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O2 -march=opteron -mtune=opteron" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks notitles sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" LANG="C" LINGUAS="en en_US en_GB fr fr_FR zh zh_CN zh_TW" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X Xaw3d alsa audiofile avi berkdb bitmap-fonts bzip2 cdparanoia cdr crypt cups dbus doc dvd dvdr dvdread eds emacs emboss encode esd ethereal exif expat fam firefox flac foomaticdb gd gdbm gif glut gnome gnutls gphoto2 gpm gstreamer gtk gtk2 hal idn imagemagick imlib jpeg kde lcms leim libwww lzw lzw-tiff mad mikmod mng mp3 mpeg ncurses nis nls offensive ogg opengl pam pcre pda pdflib perl png python quicktime readline recode sdl spell ssl tcpd tetex theora tiff truetype truetype-fonts type1-fonts udev usb userlocales vcd vorbis xine xml2 xpm xv xvid zlib linguas_en linguas_en_US linguas_en_GB linguas_fr linguas_fr_FR linguas_zh linguas_zh_CN linguas_zh_TW userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS
Are you doing this on a system that does not have a completed installation in "/" ?
No, my set-up is complete in /. Notably, linux-headers are installed correctly in /, and "emerge -1 glibc" (no ROOT set) works correctly. However, if ROOT is set, then "emerge -1 glibc". Reproduce with: mkdir /tmp/glibc-root ROOT=/tmp/glibc-root emerge system glibc is about the 4th package compiled (and it fails).
glibc-2.3.5-r2 has the following in RDEPEND and nothing in PDEPEND: nls? ( sys-devel/gettext ) selinux? ( !build? ( sys-libs/libselinux ) ) Therefore, according to glibc's deps, it doesn't require anything in the runtime root.
I ran into this problem when using catalyst (bug 115445). It appears that the glibc dependency check looks for linux-headers in the running system, but attempts to use the headers in ROOT, which may or may not be present in ROOT. A quick workaround is to ROOT=/wherever emerge -1 linux-headers, then resume with glibc...
*** Bug 115445 has been marked as a duplicate of this bug. ***
This is currently stopping release building, so I am upgrading it to a blocker, as we are nearing release time.
fixed in cvs
hey Spanky, I'll look for you on irc but what did you fix? I updated my snapshot this morning and still have the same problem.
wolf and gustavoz verified the fix on amd64/sparc
Spanky, it is still failing on ppc64. Linux headers is the last package to be emerged for stage1. What was the fix? Maybe I can poke at it too...
This was the fix in the stable glibc ebuild. Perhaps your stable version is just older? It works on glibc-2.3.5-r2 (and -r3). @@ -958,6 +959,9 @@ glibc_do_configure() { myconf="${myconf} --without-selinux" fi + # Pick out the correct location for build headers + local headersloc=$(alt_headers) + tc-is-cross-compiler && headersloc=${ROOT}${headersloc} myconf="${myconf} --without-cvs --enable-bind-now @@ -965,7 +969,7 @@ glibc_do_configure() { --host=${CTARGET_OPT:-${CTARGET}} $(use_enable profile) --without-gd - --with-headers=${ROOT}$(alt_headers) + --with-headers=${headersloc} --prefix=$(alt_prefix) --mandir=$(alt_prefix)/share/man --infodir=$(alt_prefix)/share/info
I'm seeing a problem with ~x86 and unmasked >=glibc-2.3.6, but this would appear to still effect all versions of glibc in portage. It appears that the problem is related to the check for sufficiently high level linux-headers to satisfy nptl. A change to check_kheader_version() as done in glibc_do_configure() (and toolchain-glibc_headers_compile()) should do the trick. e.g. something like : # pseudo diff check_kheader_version() { + # Pick out the correct location for build headers + local headersloc=$(alt_headers) + tc-is-cross-compiler && headersloc=${ROOT}${headersloc} - local header="${ROOT}$(alt_headers)/linux/version.h" + local header="${headersloc}/linux/version.h" It's probably (almost) worth factoring this out into another function... Anyway, the above seems to work here.
Can we get this fix backported to the latest stable glibc (glibc-2.3.4.20040808-r1)on hppa?
> A change to check_kheader_version() as done in glibc_do_configure() (and > toolchain-glibc_headers_compile()) should do the trick. e.g. something like : Which set of headers will this compile glibc against? The headers in /, or in ROOT?
added to older crusty ebuilds
(In reply to comment #13) > It appears that the problem is related to the check for sufficiently high level > linux-headers to satisfy nptl. That's the reason why catalyst stopped for me. nptl is enabled and check_kheader_version set header=/tmp/stage1root//usr/include/linux/version.h, which doesn't exit in the destination dir, although ALT_HEADERS=/usr/include is set. This fix should also go into the ebuild. Testing with an overlay now.
That blocks the ppc-release, as we do stage1 with nptl.
Well, my current suggestion would be to switch from having stage1 built with nptl, since this needs to be resolved and it should not hold up the release.
fixed in all 2.3.5 and 2.3.6 ebuilds
Created attachment 78100 [details, diff] glibc-2.3.4.20040808-r1.ebuild.patch (In reply to comment #16) > added to older crusty ebuilds > Please apply the patch, the latest in-cvs version still searchs for includes in /tmp/stage1root/usr/include.
And once again reopened.
(In reply to comment #21) > Created an attachment (id=78100) [edit] > glibc-2.3.4.20040808-r1.ebuild.patch > > Please apply the patch, the latest in-cvs version still searchs for includes in > /tmp/stage1root/usr/include. what you meant was the latest outdated version of glibc in-cvs is still broken back ported to the crappy versions
I'm still having an issue with this on HPPA while building a stage1. For the first glibc-build the headers are taken from /usr/include (which works), for the second glibc-build headers are included from /tmp/stage1root/usr/include (which doesn't work). I tested with both CVS revisions containing "the fixed" glibc-2.3.4.20040808-r1.ebuild (cvs rev 1.52 and 1.53), both failing ...
This is working for the ppc stable glibc builds, so removing ppc from the CC list.
Tobias: Is this RESOLVED now?
2.4-r2 works for sure
*** Bug 133607 has been marked as a duplicate of this bug. ***
