[oe] Kernel Headers Quality Issue

[Phil Blundell]

On Fri, 2010-05-14 at 11:25 +0200, Thilo Fromm wrote:
> No it isn't. --enable-kernel=VERSION provides kernel ABI backwards 
> compatibility to applications. *At least* the kernel ABI described in 
> the headers provided to glibc during compile time must be present at 
> runtime.

This is incorrect.  The glibc policy for a long time has been that it
should be compiled against the most recent available headers, and that
it will adapt at run time to older kernels.  See for example the FAQ:

-- 8< --

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.

{ZW} Even if you are using a 2.0 kernel on your machine, we recommend you
compile GNU libc with 2.2 kernel headers.  That way you won't have to
recompile libc if you ever upgrade to kernel 2.2.  To tell libc which
headers to use, give configure the --with-headers switch
(e.g. --with-headers=/usr/src/linux-2.2.0/include).

Note that you must configure the 2.2 kernel if you do this, otherwise libc
will be unable to find <linux/version.h>.  Just change the current directory
to the root of the 2.2 tree and do `make include/linux/version.h'.

-- >8 --

The function of the --enable-kernel option is to eliminate backwards
compatibility code for older versions: this gives you a slightly smaller
and faster library.  For example, the mmap2 syscall was introduced on
ARM at some point around kernel 2.3.35: so, if you configure glibc with
--enable-kernel=2.3.36, it knows that mmap2 must always be available and
there is no need to build the backwards compatibility logic that I
mentioned in my last email.

p.