(OLD) (ARCHIVED) Puppy Linux Discussion Forum

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?" Smile

Thanks in advance for shedding any light on this subject.

BFN.

jamesbond · Joined: 26 Feb 2007 Posts: 3475 Location: The Blue Marble

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 · Joined: 18 May 2008 Posts: 4878 Location: Blue Springs, MO

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/git/stable/linux-stable.git/tree/lib/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 · Posted: Wed 16 Mar 2016, 13:21 Post subject:

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 · Joined: 02 Apr 2007 Posts: 2647

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 · Posted: Wed 16 Mar 2016, 17:50 Post subject:

amigo · Joined: 02 Apr 2007 Posts: 2647

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 · Posted: Thu 17 Mar 2016, 13:42 Post subject:

Thanks amigo. That clears it up a bit.

boof · Joined: 26 Sep 2012 Posts: 579

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

technosaurus · Joined: 18 May 2008 Posts: 4878 Location: Blue Springs, MO

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: