Upgrading Headers?

Brian S Queen

unread,

Mar 11, 2002, 8:10:09 PM3/11/02

to

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Robert Love

unread,

Mar 11, 2002, 8:20:08 PM3/11/02

to

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

Alan Cox

unread,

Mar 11, 2002, 8:20:10 PM3/11/02

to

> 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.

David Woodhouse

unread,

Mar 12, 2002, 5:10:08 AM3/12/02

to

r...@tech9.net 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

Robert Love

unread,

Mar 12, 2002, 10:50:09 AM3/12/02

to

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

Brian S Queen

unread,

Mar 12, 2002, 12:50:09 PM3/12/02

to

Excellent! The glibc connection is what I needed to learn about. Thanks

David Ford

unread,

Mar 13, 2002, 2:40:07 PM3/13/02

to

It may be ill-advised, but it hasn't been 'broken' for the last several
years.

-d

David Woodhouse wrote:

>r...@tech9.net 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.
>