From the release of 2.26, glibc requires >=linux-3.2.0 on all architectures. See https://sourceware.org/ml/libc-alpha/2017-05/msg00058.html for upstream discussion and https://sourceware.org/git/?p=glibc.git;a=commit;h=139ace95756a61715a1 for the commit.
Does current setting cause any issues? Perhaps we should drop --enable-kernel= option and default to glibc's (lowest) default.
(In reply to Sergei Trofimovich from comment #1) > Does current setting cause any issues? > > Perhaps we should drop --enable-kernel= option and default to glibc's > (lowest) default. The ebuild should die early on if a kernel older than 3.2.0 is detected. With the current setting, it has no meaning to set --enable-kernel=2.6.32 and the build dies at the end of compilation when a newly compiled linux-3.2.0 ELF is called. I think so, we should drop --enable-kernel=. Users who want a smaller glibc can set a ore aggressive --enable kernel via EXTRA_ECONF.
(In reply to Benda Xu from comment #2) > (In reply to Sergei Trofimovich from comment #1) > > Does current setting cause any issues? > With the current setting, it has no meaning to set --enable-kernel=2.6.32 > and the build dies at the end of compilation when a newly compiled > linux-3.2.0 ELF is called. Can you provide a build log on an example system where it actually happens?
Created attachment 507478 [details] build.log.xz Sure, there you go. $ file elf/sln elf/sln: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, not stripped $ uname -a Linux kmlblo02 2.6.32-431.23.3.el6.x86_64 #1 SMP Thu Jul 31 17:20:51 UTC 2014 x86_64 ....
Ok, so it's not about --enable-kernel= flag at all but about the check for minimal currently running kernel version that toolchain-glibc.eclass:check_nptl_support() happens to perform as part of NRPL presence check.
(In reply to Sergei Trofimovich from comment #5) > Ok, so it's not about --enable-kernel= flag at all but about the check for > minimal currently running kernel version that > toolchain-glibc.eclass:check_nptl_support() happens to perform as part of > NRPL presence check. No, it's not. We just need to let glibc die earlier somehow when the running kernel is too old.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cdeeef2c38cdb2ddd66fbc1fbce2b5af97f09c82 commit cdeeef2c38cdb2ddd66fbc1fbce2b5af97f09c82 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2017-12-02 16:36:16 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2017-12-02 16:36:36 +0000 sys-libs/glibc: Update NPTL_KERN_VER to 3.2 (minimum required by glibc-2.26) The entire kernel version check needs rework (but that's something for >2.26). Closes: https://bugs.gentoo.org/639152 Package-Manager: Portage-2.3.16, Repoman-2.3.6 sys-libs/glibc/Manifest | 2 +- sys-libs/glibc/glibc-2.26-r3.ebuild | 4 ++-- sys-libs/glibc/glibc-9999.ebuild | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-)
