I am running Slackware64-current(multi-lib) and I have stumbled across something that I don't fully understand.

I have read that the kernel-headers should not be updated as glibc is compiled against them and therefore requires that set of kernel headers. Recently the kernel version has been bumped a couple of times but glibc has stayed the same.

Should glibc be re-compiled each time there is a kernel update?

Perhaps someone can explain, in very simple terms, the relationship between the kernel, the kernel headers, the kernel modules and glibc.

samac

The kernel is a collection of subroutines that provide an interface to access the hardware, managing system resources, accessing files, etc.

The userspace, that is where normal applications run, use a well defined interface to talk to the kernel. The relevant definitions of data structures and mappings between symbolic names for commands and their actual values can be found in the kernel headers. If you update the kernel, the ABI will not change in general. (Except for major updates, but this will also break all other applications and requires to recompile them). Nevertheless the naming of certain symbols in the headers can change from time to time. So replacing the kernel headers with newer one, will probably make you unable to compile new applications.

The kernel headers do also describe the interface of different parts within the kernel. For example how a sound driver should interface the sound system.
These definitions do not affect the userspace and glibc.

Kernel modules are some kind of plugin for the kernel and have to be recompiled after each kernel update. (But there is no rule without exception).

Since glibc acts as an intermediate layer between the kernel and the normal user applications, it depends on the definitions of the ABI to the kernel and thus require the kernel headers.

Thanks for the answer, I almost got some of it.

Two questions:

ABI?
Is that a yes or no?

samac

ABI = application binary interface

This how the interface looks like on the compiled (binary) level. Except for major kernel updates (e.g. 2.4.x -> 2.6.x or 1.x -> 2.x) it should not be necessary to update glibc. Only to utilize eventual new features you will have to recompile glibc.

ABI : (Application Binary Interface)
A specification for a specific hardware platform combined
with the operating system. .. ..
http://dictionary.zdnet.com/definition/ABI.html

No, you never touch or upgrade glibc, unless an updated
build is announced for your OS. Usually minor fixes
to the version, you already have.

Changing glibc : Will most often require a complete
reinstall of the OS.
.....

Alien Bob explains the different types of kernel headers well here
An Application Binary interface - basically rules to access the kernel.

No - you don't need to update glibc for a new kernel.

OK so you should not upgrade your kernel-headers package. So why is it updated along with the kernel updates in current? I was not planning on updating glibc I was referring to the fact that the kernel-headers have been updated, so surely glibc should be compiled against these new headers. Perhaps someone can shed some light on this apparent anomaly.

samac

Also how can you tell which set of kernel headers glibc is compiled against?

samac

/lib64/libc.so.6 or /lib/libc.so.6 will reveal all compilation settings. (Just call the shared library as it was a executable).

OK glibc is compile against 2.6.29.6, so that suggests that kernel-header-2.6.29.6 is the version that should be installed on all versions of Slackware13.0 and Slackware-current. So if this is the case, why have the kernel-headers been update 4 times in current since that point. Should the updates in current be there?

samac

Actually, running /lib/libc.so.6 does *not* tell you which kernel headers were used to compile glibc -it tells you which version of the kernel was *running* when glibc was compiled and this is not always the same as the kernel-headers used.

AAARRRGGGHHHHH!!!!!!

So Gilbert what version of kernel-headers would you use?

samac

The replies you've already had cover pretty much everything (kudos to the repliers - great info here) you need to determine the answers to your questions, but let's take a look anyway

Spinning this 'round a bit: would you rebuild glibc every time you installed a custom kernel? The answer is probably no. In general it's not necessary to do so. The conditions under which you *need* to rebuild glibc are listed above.

I could speculate on why you're seeing this discrepancy in -current, but I figure someone with authority will speak sooner rather than later, and I don't want to muddy the waters.

The answer to this is really that there is no simple terms - the relationships are intertwined. If you can program a bit of C or C++, have a google around for static and dynamic linking, and what effect they have on program. Then actually look at what glibc provides when you link against it (hint: std*.h). Hopefully you'll have enough of the jigsaw to at least see what the picture's supposed to be

I've written a bit about both these sort of questions before here, but the information above is far more complete!

I would reiterate though, that it's a good idea to keep a copy of the headers glibc was built against available (in slack, this is the kernel source package iirc) regardless of what (custom built) kernel you're actually running.

Keep on learning!
- Piete.

how about 'scsi.h'? Why it needs the glibc ones??

From alien-bob's kernel-how-to: