Which C library is the kernel compiled against?

[musher0]

Hello all.

As the title and the sub-title say.

Context: "The Pooch" (working title), in other words the experimental dpup-3.14.56.1
I'm currently working on.

If I want to update both the the C library and the kernel for this would-be Pup, which
one should I start compiling first?

For example, there's an update to the 3.14 kernel, 3.14 63, just out March 3rd.
(Please see -- https://www.kernel.org --.)

I'm not promising anything, but, for the sake of example:

if I tried to compile the 3.14.63 kernel against the existing 2.13 version of the C
library in "The Pooch", would the kernel and modules be limited to this C library
version 2.13?

If later I compile C library version 2.23 (still as an example; most likely a lesser
version), could this kernel and modules compiled against v. 2.13 be usable?

A second example, if I may, to view this question from a different angle:
dejan555's dpup-4.87 already has C library version 2.20, but an old kernel, 2.32,
IIRC. Could one compile the latest (as of this writing) kernel version 4.4.4 against
it? And then would it be portable to "The Pooch"?

(I'm using dejan's Pup, and lib and kernel versions as examples, but doing so,
I am not hinting at anything or targeting anyone. I'm just trying to get to the
general principle, and these two DPups are what came to mind.)

Like in the folk saying: "Which comes first: the hen or the egg?"

Thanks in advance for shedding any light on this subject.

BFN.

[jamesbond]

libc depends on kernel, not the other way around.
Try to run this in terminal: "/lib/libc.so.6", and you will see which kernel version the libc was built against.

It is mostly okay to update kernels without updating glibc. The worst that could happen is glibc won't be able to use newer kernel features.
It is also mostly okay to upgrade glibc without updating kernel, as long as that glibc is compiled for the same (or older) kernels.

Remember, however, if you build updated glibc you may end-up having to update you *entire toolchain* (binutils, gcc, etc).

[technosaurus]

The kernel only uses a subset of the C standard library (only what is needed) and where the standard doesn't fit with what they need they adjust accordingly.
for example:
http://git.kernel.org/cgit/linux/kernel ... vsprintf.c

@jamesbond's advice about glibc is a glibc bug. Other C standards don't necessarily have those problems. Musl libc, for instance, can be used on older or newer kernels and will just return -ENOSYS if a particular syscall is not implemented on an older kernel

[musher0]

Hi technosaurus.

Good to hear from you. Thanks for your input.

Maybe the following is heresy?
(I wouldn't know, I'm a neophyte in these matters, sorry in advance for ruffled feathers...)

If you compile a kernel with musl C, can this kernel be used on another Pup that only
has the "regular" C lib?

And speaking of which, could you create an entire Puppy based on musl C?
E.g., a Puppy derivative of the Alpine distro?

The reasoning behind this being:
Since the Woof-CE process makes would-be developers sweat and the resulting
Puppies are more or less clones of each other anyway, might as well sweat to introduce
a really new concept.

Feasable ? Unfeasable? TIA for any opinion.

The musl C library being small, wouldn't it be a natural match for the Puppy approach?

BFN.

[amigo]

You don't compile the kernel with *any* C library. The code is completely stand-alone and references no outside anything. On the other hand, when compiling glibc one compiles against headers (includes) from a (some) kernel, while also defining the minimum kernel version needed to use the libs, and also defining the level of backward compatibility for programs which were compiled against earlier versions of glibc. musl, dietlibc & Co. do things their own way.

Again, the kernel is not compiled 'against' or 'linked to' anything, either at compile-time or runtime. The kernel needs no libc in order to 'run'.

[musher0]

You don't compile the kernel with *any* C library. The code is completely stand-alone and references no outside anything. On the other hand, when compiling glibc one compiles against headers (includes) from a (some) kernel, while also defining the minimum kernel version needed to use the libs, and also defining the level of backward compatibility for programs which were compiled against earlier versions of glibc. musl, dietlibc & Co. do things their own way.

Again, the kernel is not compiled 'against' or 'linked to' anything, either at compile-time or runtime. The kernel needs no libc in order to 'run'.

Finally the cat is out of the bag! Many thanks, amigo.

So to restate this in my words:
1) the kernel compiles as stand-alone
2) glibc compiles with some "includes" provided by the kernel when it was compiled.
Have I got this right?

But how do I "define" the following:
> ... while also defining
-- the minimum kernel version needed to use the libs, and
-- the level of backward compatibility for programs which were compiled against earlier versions of glibc.
Are there some boxes to tick in the kernel configuration interface?

Thanks in advance.

[amigo]

Min kernel version and glibc-backward are configuration options for glibc, not the kernel.

Also, note that the kernel version of the headers used to compile glibc, doesn't have to be the same as the min kernel version, nor the kernel running while compiling.

In short, the kernel is completely divorced from glibc.

[musher0]

Thanks amigo. That clears it up a bit.

[boof]

The kernel is already compiled-is that what you're saying? against assembler, if memory serves?

[technosaurus]

No, it is written in C with some assembly for architecture dependent details or speed. You don't need a libc at all to compile c; C != libc just like C++ != STL (a.k.a. libstdc++ for glibc based systems).
When you just use C primitive operations like +,-,*,&,|,/,>>,<<, etc... and don't call any external libc functions, you don't need to link to it. For example:

Code: Select all

int mystrlen(const char *s){int i=0;while (*s++)i++;return i;}
int main(int argc, char **argv){return mystrlen(argv[0]);}
//gcc -nostdlib -o thislen thislen.c
//it still uses the startfiles though usually crt*.o
//should return the length of the command used to run the executable

The kernel implements any and all functions that it needs internally and is built in standalone mode (no "_start()" or "main()" required ... it just starts executing at a given address), so when you build a kernel with gcc for instance, it doesn't matter what C library gcc was built against, nothing gets linked into the kernel except what is in the kernel tree... kind of like building a musl static binary on a glibc system.