Issues with linux-libc-headers, incompatibility between kernels
drealin01 at cox.net
Sun Apr 30 15:22:19 PDT 2006
Okay, it has been argued in many ways over how using a stable kernel headers will resultin better practice.
However, there are two major issues at hand.
First, the linux kernel has been undergoing insanely large number of changes between minor version (aka 2.6.12 vs 2.6.13).
Secondly, the linux-libc-headers worker has not been able to keep it up to date.
After some numerous testing, I have found that many of the changes directly effect the compilation of the system, as HLFS is a scratch system.
What this means is that:
1) Stability of the system as a whole becomes damaged, in such a way that uneasily traced bugs occur. The perfect example for this was the agpgart.h problems and Xorg. (The entire structue of the linux/agpgart.h file has changed and relates in almost no way, when comparing 2.6.12 and 2.6.16.)
2) For stability purposes you must either compile with 2.6.12 and use the 2.6.12 kernel (insecure), or directly use the 2.6.16 headers (considered bad practice).
3) The linux headers from any kernel 2.6.12 -> 2.6.17 have very little relation to each other, the code has changed THAT much, betwen minor versions!
Seeing as how the 2.6.16 kernel is supposed to be stable, it would be to our greatest benefit to stick with those headers and not the 2.6.12.
One problem arised when compiling against the 2.6.16 kernel headers, the linux/version.h does not exist, I had to copy and hack the one from 2.6.12.
I have successfully compiled the toolchain under uClibc using this method and will report further problems from this.
I have also noted that the linux headers from 2.6.16 also have #defines that prevent it from including private headers when not using the kernel source.
More information about the hlfs-dev