LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Should glibc be updated in current every time there is a kernel update? (https://www.linuxquestions.org/questions/slackware-14/should-glibc-be-updated-in-current-every-time-there-is-a-kernel-update-788256/)

samac 02-10-2010 10:58 AM

Should glibc be updated in current every time there is a kernel update?
 
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

irmin 02-10-2010 11:23 AM

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.

samac 02-10-2010 11:31 AM

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

Two questions:

ABI?
Is that a yes or no?

samac

irmin 02-10-2010 11:51 AM

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.

knudfl 02-10-2010 11:55 AM

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.
.....

bgeddy 02-10-2010 11:55 AM

Alien Bob explains the different types of kernel headers well here
Quote:

ABI
An Application Binary interface - basically rules to access the kernel.

Quote:

Is that a yes or no?
No - you don't need to update glibc for a new kernel.

samac 02-10-2010 12:19 PM

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

samac 02-10-2010 12:29 PM

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

samac

irmin 02-10-2010 12:46 PM

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

samac 02-10-2010 01:04 PM

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

gnashley 02-10-2010 01:25 PM

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.

samac 02-10-2010 01:41 PM

AAARRRGGGHHHHH!!!!!!

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

samac

piete 02-10-2010 05:18 PM

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 :)

Quote:

Should glibc be re-compiled each time there is a kernel update?
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.

Quote:

Perhaps someone can explain, in very simple terms, the relationship between the kernel, the kernel headers, the kernel modules and glibc.
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.

BrZ 02-10-2010 06:58 PM

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

damgar 02-10-2010 07:03 PM

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

Slackware kernel-headers package

You are going to build and use a new kernel. You may wonder what you need to do with the Slackware kernel-headers package.
The answer is: do not remove this package!

There are two places where you will find kernel headers; one place is inside the kernel source directory (in our case, the /usr/src/linux-2.6.27.7 directory) and the other place is /usr/include/linux. The kernel-headers package usually contains the headers taken from the source of the default Slackware kernel. These particular headers are used when the glibc package is built. The fact that the kernel-headers package installs these files to /usr/include/linux makes them independent of the header files you find in the kernel source directory.

As long as you do not upgrade your glibc package, you should not upgrade or remove the kernel-headers package.


All times are GMT -5. The time now is 01:19 AM.