sys-kernel/linux-headers-3.14 is no longer in tree while there is still sys-kernel/gentoo-sources-3.14.X in tree. One really need matching headers to make glibc happy. Otherwise glibc thinks kernel supports some fancy new feature which isn't there and apps starts to malfunction. Please restore above headers.
err, no, glibc doesn't do that at all. kernel headers are used to *optionally* test & use a feature, but if it's not available, glibc will *transparently* fall back to the features that are available based on the min kernel version. you can see that value easily: $ file -L /lib/libc.so.6 /lib/libc.so.6: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, stripped that glibc is guaranteed to work on linux-2.6.32 and newer even though it was built against a much newer kernel headers version (4.2 in my case). if you know of an actual bug where glibc misbehaves on an older kernel, please file a bug upstream for glibc (and feel free to cc me): http://sourceware.org/bugzilla/
I remember 2 incidents from our server park, one was samba using a newer syscall than was available. Then other one was related to NFS I think. Even if this wasn't glibc's fault, using newer kernel headers is just asking for trouble for no gain. Please, just leave matching headers in tree until the corresponding kernel is gone.
(In reply to Joakim Tjernlund from comment #2) sorry, but no. if you have bugs, we'll look.
(In reply to SpanKY from comment #3) > (In reply to Joakim Tjernlund from comment #2) > > sorry, but no. if you have bugs, we'll look. Not ATM. The 2 problems I mentioned are history and I learnt to never use newer headers than the kernel. There is nothing to be gained using newer headers, just headache. I can see that a distribution wants this freedom but why take this risk when you don't have to?
(In reply to Joakim Tjernlund from comment #4) we actively support newer headers on older kernels (as do a lot of distros), and i haven't generally run into a problem. i don't think it's nearly as dangerous as you make out. if you hit a bug, report it. we don't generally operate on anecdotes.
(In reply to SpanKY from comment #5) > (In reply to Joakim Tjernlund from comment #4) > > we actively support newer headers on older kernels (as do a lot of distros), > and i haven't generally run into a problem. i don't think it's nearly as > dangerous as you make out. Sure, it probably works well for most. We had the misfortune to hit bugs twice on our servers and since then we just decided to use matching headers whenever possible. > > if you hit a bug, report it. we don't generally operate on anecdotes. I will but that is not likely to happen due to: 1) We will do our best to keep them in sync. 2) If an busy server misbehaves due we generally don't have time to investigate that much, just fix it fast as possible. I just didn't think it would be a problem to hang on to older headers for as long there are corresponding sources in tree. Anyhow, now I know and will stop here.
- install a fresh gentoo machine - it has linux-headers 3.18 - run kernel 3.14 (LTS) - build net-misc/openntpd-5.7_p4-r2 and get an error, because glibc (built with 3.18 headers) generated (https://bugs.gentoo.org/show_bug.cgi?id=565570): # grep -ri getrandom /usr/include/ /usr/include/bits/syscall.h:#define SYS_getrandom __NR_getrandom /usr/include/bits/syscall.h:#define SYS_getrandom __NR_getrandom /usr/include/bits/syscall.h:#define SYS_getrandom __NR_getrandom and so openntpd thinks it has SYS_getrandom: #ifdef SYS_getrandom ... Solution is to install linux-headers-3.14, recompile glibc, then we bits/syscall.h does not define SYS_getrandom as it was introduced in kernel 3.17.
(In reply to Tomas Mozes from comment #7) > - install a fresh gentoo machine > - it has linux-headers 3.18 > - run kernel 3.14 (LTS) > - build net-misc/openntpd-5.7_p4-r2 and get an error, because glibc (built > with 3.18 headers) generated > (https://bugs.gentoo.org/show_bug.cgi?id=565570): > > # grep -ri getrandom /usr/include/ > /usr/include/bits/syscall.h:#define SYS_getrandom __NR_getrandom > /usr/include/bits/syscall.h:#define SYS_getrandom __NR_getrandom > /usr/include/bits/syscall.h:#define SYS_getrandom __NR_getrandom > > and so openntpd thinks it has SYS_getrandom: > > #ifdef SYS_getrandom > ... > > Solution is to install linux-headers-3.14, recompile glibc, then we > bits/syscall.h does not define SYS_getrandom as it was introduced in kernel > 3.17. Right, we had a similar problem with Samba some years ago. While glibc might do the right thing, apps do not. There is no easy fix for this type of errors other than to keep linux-headers in sync with your kernel. There should be matching headers to every stable kernel in the repo.
(In reply to Tomas Mozes from comment #7) that's a bug in openntpd. file one against it.
