Bernd Feldmeier wrote:
a) dependency of kernel version and linux-libc-header version
None whatsoever. These are two different packages, with two different
reasons for existing.
l-l-h is based on the kernel headers, but you can use any version of
either of them (well, no, that isn't quite right: your kernel version
has to be = your l-l-h version, because the kernel contains backwards
compatibility code, but it does not have to be ==).
b) problems occuring
Problems when you try to do what?
If you upgrade l-l-h (and the kernel) without recompiling glibc, any
programs you compile against the new l-l-h headers could break when they
try to call functions in the glibc that never got changed. (See Linus's
comments, which have been linked to by several people in this thread.)
If you upgrade the kernel without upgrading l-l-h or glibc, then you
have no problems. The kernel keeps all sorts of back-compat code in so
that programs (and libraries, i.e. glibc) that use older versions of its
userspace ABI can still work.
If you upgrade the kernel without upgrading l-l-h or glibc, *and* you
need to compile a program that (1) needs a feature present in the new
kernel, but (2) does not include its own local header for that feature,
then you won't be able to compile the program. But this is a bug in the
program, not a reason to keep kernel and l-l-h versions in sync. When
you're using a brand-new feature, you better be keeping your own version
of that feature's header files, so you can compile against slightly
older glibcs.
c) real meaning of sanatized headers (why ...)
Because the headers right out of the kernel contain all kinds of cruft
that userspace doesn't need to see or use. (Plus they're bigger, so
compilation takes slightly longer.) Plus they use the *wrong* names for
several structures and structure members (IPv6), and therefore will
*never* work with RFC-compliant user programs.
d) creating our own up-to-date header version
IMO, that's way too much work, since it's already being done by l-l-h.
e) libc + kernel interface calls
I'm not sure what you mean here...
signature.asc
Description: OpenPGP digital signature
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
