Hello

This is a newbie question: What is the connection between the kernel and Libc (either gLibc, uClibc, etc.)?

For instance, what happens if I upgrade the kernel but keep an older version of Libc and applications that rely on it: Will applications keep running, and I will need to upgrade Libc only if I install newer applications that expect to find new systems calls in the kernel that they reach through Libc?

Or are the kernel and Libc totally unrelated?

Thank you.

Sounds like you need to do yourself a linux from scratch.

At it's simplest, header files are subroutines, and libraries are compiled routines. When the kernel decides to write to disk, or screen, for example it calls on routines compiled in the libc of your choice, which know how to address the chips on the board and make that write happen. That's the relationship.

Software writers are able to ignore all those details of sending control codes to specific addresses to instruct chips, and then sending data.

Thanks for the infos. So upgrading the kernel without upgrading the Libc could be a problem, since the kernel might expect new functions that weren't yet available in the current Libc version.

The kernel cannot use any libraries ... which is why it contains its own simplified implementations of things like printf().

The glibc library is very important, however, since most of the system (including key command-line tools...) uses it. Therefore, this library is both critically important and "not quite like all the others."

However, it is "like all the others" in one respect ... namely, that you can have more than one of them on your system at the same time, if you need to.

Nevertheless: in all aspects concerning this library, I strongly encourage you (nay, "I command thee!") not to touch this library except through distro-provided packages and strictly according to the distro's instructions. Admire the blinking lights, but don't touch. You can get your system thoroughly hosed very quickly, because this library is so very pervasive.

The connection is the other way around: apps use libc (whatever libc you want), and libc translates anything (like printf) into system calls, or plainly spoken, they ask the kernel to do something. Programs can also use direct system calls and bypass libc, but that's not a common thing to do, unless you seek a very specific and obscure purpose.

Take a look here:

http://www.win.tue.nl/~aeb/linux/lk/lk-3.html

That you will find a kernel version that will not work with a given version of glibc is extremely unlikely to happen, unless you use a very very old glibc in a very very new kernel, or vice versa. Being that said, using any libc others than the ones supported in your distro (and version) is usually doomed to failure, because all the programs that links against libc will be unable to run, and that usually means 100% of your binaries, except, maybe, a static version of grub and the like.

The kernel will still run but after that, init will fail if your new libc is incompatible with your user land. Even in source based distros like Gentoo you have to be careful when updating glibc, and downgrading it is completely unsupported and not straightforward.

Thanks for the clarification. So both the kernel and C applications use some C library, but the kernel compiles it statically, while applications usually use the shared version.

Is the C library used by the kernel the same as gLibc but only includes a subset of the functions available in gLibc, or is it a totally different library rewritten from scratch to fit the needs of the kernel?

Re-read (the start of) post #4. Stop when you get to the ellipsis.

But then, what difference does it make if the C functions are in the kernel source code or in some library, as long as the library is statically compiled?