glibc problems with too recent kernel headers

[Pekka Savola <pekkas at netcore dot fi>]

Hi,

There seem to be cases, where glibc is including too recent version of the 
linux kernel header and this is breaking applications. The FAQ that says this 
should be OK seems to be wrong [1].

One specific example of this is that since glibc 2.4, IPV6_PKTINFO and 
several other IPV6 socket definitions were updated.  The existing 
numbers were changed [2] (causing problems), and new ones were added 
(causing other kinds of problems).

As a result, an application recompiled on that glibc version where the 
kernel is not recent enough (in this case, >= 2.6.14), using those 
definitions fail, resulting in errors such as setsockopt returning 
ENOPROTOOPT.

As an application maintainer, I've had to create a workaround for this 
(pretty nasty, and doesn't cover all the cases) [3].

I'd like glibc to better document the required kernel version to run a specific 
version of glibc, FAQ updated and/or some other logic put in place to avoid 
recompiled applications breaking when glibc is more recent than the kernel.

[1]
1.8.    What version of the Linux kernel headers should be used?

{AJ,UD} The headers from the most recent Linux kernel should be used. The 
headers used while compiling the GNU C library and the kernel binary used when 
using the library do not need to match.  The GNU C library runs without 
problems on kernels that are older than the kernel headers used.  The other way 
round (compiling the GNU C library with old kernel headers and running on a 
recent kernel) does not necessarily work.  For example you can't use new kernel 
features if you used old kernel headers to compile the GNU C library.
...

[2]
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/bits/in.h.diff?r1=1.17&r2=1.18&cvsroot=glibc

[3]
http://cvs.litech.org/viewcvs/radvd/radvd.h?r1=1.27&r2=1.28

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings