WDef
Group: Members
Posts: 798
Joined: Sep. 2005 |
|
Posted: July 01 2007,22:14 |
|
@Mikshaw: thanks.
@Juanito: Are you confusing "linux-kernel-headers" with the actual kernel sources? You wouldn't be the first!
Warning: sermon approaching :=)
linux-kernel-headers are not the kernel headers (at least not necessarily) of the running kernel. Instead, they are the contents of /usr/include/linux which are the headers from the kernel sources against which the system's glibc was compiled. (Back to that central glibc again). So these are the headers that match the library object files.
This confusing terminology arose because, in the old days, these headers were all the same thing. glibc was compiled against the kernel that the linux pioneers were running. So a (bad) custom developed of just symlinking /usr/include/{linux,asm} to /usr/src/linux/include/{linux,asm}. Why not, it's just duplicating the same stuff, right? In fact Klaus Knopper made a "linux-kernel-headers" package that are just those symlinks I think. To which I posted on the Knoppix mail list asking for clarification about that, but never got a response.
But once you change the running kernel without recompiling glibc (which is the usual situation), then these headers are different. So the /usr/include/{linux,asm} headers have to be kept the same as those matching glibc and shouldn't change unless you change/rebuild glibc. glibc can only use the functions and calls defined by the headers it was built against. Therefore other progs on the system should use these same headers when compiling.
Which is why Linus Torvalds says we should never compile new kernels in /usr/src/linux, or if we do, we should get rid of those symlinks and make sure the contents of /usr/include/{linux,asm} do match the running glibc.
So Woody's "linux-kernel-headers" have to match its glibc, not the kernel-du-jour. At least that's my (quite probably imperfect) understanding.
This is also why the maker of the linux-kernel-headers extension in the repo says these are kernel independent or something in the info file, which is a bit of an approximation.
</end sermon>
RE: gcc1-with-libs.dsl - I know there is at least one header in there that mismatches the lib version on the system - I think from memory it's libpng2. Needs fixing.
:0
|