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
