When a person switches to, or upgrades a kernel, how do they upgrade the
associated header files? The headers in /usr/include won't match the kernel.
I don't see anything about that in the documentation.
When I want to program with my new kernel I need to use the new headers, so I
have to use #include <linux/fcntl.h> instead of #include <fcntl.h>. This
seems odd.
Brian McQueen
NAS Division
NASA/Ames
On Mon, 2002-03-11 at 20:00, Brian S Queen wrote:
> When a person switches to, or upgrades a kernel, how do they upgrade the
> associated header files? The headers in /usr/include won't match the kernel.
> I don't see anything about that in the documentation.
>
> When I want to program with my new kernel I need to use the new headers, so I
> have to use #include <linux/fcntl.h> instead of #include <fcntl.h>. This
> seems odd.
You don't. The headers in /usr/include/linux and /usr/include/asm
(which may be a symlink to /usr/src/linux/include/linux and
/usr/src/linux/include/asm, respectively) should point to the kernel
headers that were present when _glibc_ was compiled.
Thus the kernel headers should match your current glibc, not your
current kernel. This is fine because the kernel will maintain backward
compatibility with the previous interfaces.
If there is something in the new kernel you want/need, recompile your
glibc against those new kernel headers and install accordingly.
Robert Love
> When a person switches to, or upgrades a kernel, how do they upgrade the
> associated header files? The headers in /usr/include won't match the kernel.
> I don't see anything about that in the documentation.
Thats intentional.
> When I want to program with my new kernel I need to use the new headers, so I
> have to use #include <linux/fcntl.h> instead of #include <fcntl.h>. This
> seems odd.
You want a newer glibc basically (or for specific cases just fix the headers)
The point is that glibc<->app and kernel<->glibc do not match. Eg glibc had
32bit uid_t well before the kernel did - as a result moving the kernel
to 32bit uid has been almost painless.
[email protected] said:
> You don't. The headers in /usr/include/linux and /usr/include/asm
> (which may be a symlink to /usr/src/linux/include/linux and /usr/src/
> linux/include/asm, respectively) should point to the kernel headers
> that were present when _glibc_ was compiled.
No it may not be a symlink. That would be broken.
--
dwmw2
On Tue, 2002-03-12 at 05:02, David Woodhouse wrote:
> No it may not be a symlink. That would be broken.
Well, I've seen it as a symlink, but then you are not supposed to
recompile out of /usr/src/linux ... that was why, I assumed, Linus
suggested everyone compile there kernels out of /home in the last
discussion about this.
Admittedly it should not be linked, but I think it is often enough - the
same rule stands: don't change the src without recompiling glibc.
Robert Love
Excellent! The glibc connection is what I needed to learn about. Thanks
It may be ill-advised, but it hasn't been 'broken' for the last several
years.
-d
David Woodhouse wrote:
>[email protected] said:
>
>> You don't. The headers in /usr/include/linux and /usr/include/asm
>>(which may be a symlink to /usr/src/linux/include/linux and /usr/src/
>>linux/include/asm, respectively) should point to the kernel headers
>>that were present when _glibc_ was compiled.
>>
>
>No it may not be a symlink. That would be broken.
>