Didier Kryn <kryn@???> writes:
> Le 25/05/2016 18:55, Rainer Weikusat a écrit :
>> Linux has the nice policy of never changing a public ABI, hence, there's
>> no problem in this respect
>

>     Good to know. Although this is not true for kernel internals (if
> you write or maintain a driver) and it obviously cannot apply to new
> features.

>

>     Actually I've never been so afraid about that and often ran libcs
> compiled matching kernel versions newer or older than the running
> one. This was just a warning.

In order to avoid problems in this respect, the running kernel version
needs to be >= the kernel version the C library was compiled (and
written) for and application using 'linux headers' need to be compiled
with the same set of linux headers the C library was compiled with.
This way, it's ascertained that the running kernel supports all features
the C library uses and supports them in a way compatible with it and
that applications and C library agree on how to use a certain kernel
feature.

As 'kernel updates' will usually be updates, ie, use a newer kernel than
the one shipped with the distribution, there's no reason to worry about
any of this on a post-libc5 system: Compiling and installing a new
kernel should 'just work', it just (obviously) won't enable the C
library to take advantage of newer features. If this is an issue, a
newer C library can be installed from source in addition[*] to the
system-provided one and applications can be compiled/ linked such that
they use the newer library.

[*] BIG FAT WARNING: Do not ever try to update the system C library to a
    newer version by doing a 'make install' after compiling that unless
    you're curious and don't really need to use the system in question
    for anything.