Didier Kryn <k...@in2p3.fr> 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.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
