In the course of installing glibc, a kernel version check is conducted so as to ensure that the host is running a kernel >= 2.6.9: * Checking kernel version (3.4.11 >= 2.6.9) ... [OK] * Checking linux-headers version (3.4.0 >= 2.6.9) ... [OK] I understand that the purpose of this check is to prevent a modern version of glibc from being merged to the root filesystem of a host running a kernel which cannot support NPTL, due to NPTL being mandatory in glibc these days. If so, then the nature of the test appears to be bogus. On my systems, removing the /usr/src/linux symlink is sufficient to trigger the following: * ERROR: sys-libs/glibc-2.15-r2 failed (unpack phase): * toolchain-funcs.eclass: Kernel version could not be determined, please inherit kernel-2 or linux-info I'm not sure why removing the symlink is sufficient for this test to fail but I suspect it is related to the patch committed from bug 436450. However, my point would be that neither the symlink nor the installed sources (as per packages in the sys-kernel/ category) are reliable indicators of the *currently* running kernel. Therefore, I don't understand why they should have any bearing on the glibc test. If the purpose is indeed to prevent glibc from being installed on a host running an old kernel then surely calling upon uname is the only viable test that can be performed? With 2.6.9 being 8 years old, is this test even useful now? I became aware of this issue after speaking to two Gentoo users who are now unable to upgrade glibc on a Linode VPS. These use Xen and they confirmed that there is no /usr/src/linux symlink. It should not be required though. For the record, they were actually running 3.5.2 kernels which, obviously, is safe.
Correction: I meant to refer to bug 432390 (not bug 436450, though it is related).
This also applies to openvz containers, updating glibc has become impossible. >>> Emerging (1 of 2) sys-libs/glibc-2.15-r3 * glibc-2.15.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * glibc-ports-2.15.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * glibc-2.15-patches-22.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] make -s glibc-test make -s glibc-test >>> Unpacking source... * ERROR: sys-libs/glibc-2.15-r3 failed (unpack phase): * toolchain-funcs.eclass: Kernel version could not be determined, please inherit kernel-2 or linux-info * * Call stack: * ebuild.sh, line 85: Called src_unpack * environment, line 3507: Called eblit-run 'src_unpack' * environment, line 876: Called eblit-glibc-src_unpack * src_unpack.eblit, line 166: Called setup_env * common.eblit, line 276: Called setup_flags * common.eblit, line 162: Called setup_target_flags * common.eblit, line 43: Called tc-arch * environment, line 3587: Called tc-ninja_magic_to_arch 'portage' * environment, line 3889: Called die * The specific snippet of code: * [[ -z ${KV} ]] && die "toolchain-funcs.eclass: Kernel version could not be determined, please inherit kernel-2 or linux-info";
(In reply to comment #0) the check has nothing to do with nptl. glibc has a sliding min kernel version, and if you're running an older kernel, then you're out of luck. glibc-2.16 moves that line up to 2.6.16. *** This bug has been marked as a duplicate of bug 432390 ***
I don't think this is a duplicate. The whole point of this bug is not that a change in circumstances causes the check to fail but that the check is potentially useless. I thought I made that clear. Whether it be 2.6.9, 2.6.16, for establishing presence of NPTL or not, exactly how is deriving a kernel version from installed sources or a symlink relevant? The symlink tells us nothing beyond the fact that a user has a certain set of sources installed. Let me put it another way: if I'm running 2.6.8 but have newer sources installed, the ebuild will be satisfied that I have a recent kernel version. But if I'm not running it, what's the point? What is being safeguarded in this instance? As far as I can tell, the answer is "nothing". If I am actually mistaken in that assertion, can you at least explain why in your closing comment.
(In reply to comment #4) you misinterpreted the error. the glibc ebuild *doesn't* get the version from the symlinks. it gets it from `uname -r`. if it did actually get it from the symlinks, you wouldn't even have seen the output that you did.
So I did. I should be mindful that correlation does not imply causation. Thanks.
It looks like Kerin has actually found something else, unrelated to the glibc ebuild's kernel version checks. The original fix from bug 432390 would throw an error and die if both $KV and $KV_FULL were unset (by trying to set $KV to $KV_FULL if $KV was previously unset, and then checking to see if $KV was set). Kerin was unable to reproduce the issue that other users were seeing. The only difference we found between systems was that Kerin had a kernel source package installed, whereas everybody else did not. Something, be it portage, the glibc ebuild, or some other eclass, is populating either $KV or $KV_FULL solely because of the /usr/src/linux symlink pointing to somewhere useful.
