This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

concerning headers, glibc, and kernel upgrades

Hi! I am in the process of de-blobbing Slackware, and one of my basic
tasks consists in replacing the stock kernel with Linux-libre kernel.
Not content with merely de-blobbing the kernel, I would like to explore
the option of upgrading it, but then some questions arise.

Please excuse me if my questions are confusing or ill-informed, as I
lack expertise in kernel-related issues.

My question concerns the interplay between Linux-libre, glibc, and
the so-called kernel headers used by glibc. The wiki says:

> 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 as expected. For example you can't use
> new kernel features if you used old kernel headers to compile the
> GNU C library.

> Even if you are using an older kernel on your machine, we
> recommend you compile GNU libc with the most current kernel
> headers.  That way you won't have to recompile libc if you ever
> upgrade to a newer kernel.

So let's say glibc is built against kernel headers 3.18.* and the kernel
in use is 3.10.17. So there is a version mismatch. Isn't it possible that
some interface is different, like some struct has changed size, and then
glibc calls to kernel (or some other app calls through gibc) and kaboom?
How likely is this scenario? Would it not be safer to match headers with
the kernel?

Here's a related question.

Traditionally, Slackware -stable has kernel, headers, and glibc frozen,
with headers matching the kernel. The kernel is never upgraded (afaik),
instead individual commits are applied to the kernel when a particularly
severe hole is discovered. All of this done, seemingly, for the fear of

Now (and forgive me if this question is too Slackware-specific), what
would be a good way to upgrade the kernel? Is bumping the headers to
mainline really better than bumping them to the new kernel version,
even though the former results in mismatch? But more importantly, what
exactly should be rebuilt? Is it enough to rebuild the kernel, install
the new headers, then rebuild glibc against the new headers? Or should
I also rebuild other parts of the gcc toolchain?

Thank you in advance!

Attachment: signature.asc
Description: OpenPGP digital signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]