Re: kernel-headers-2.0.32 vs. kernel-headers-2.0.33
On 13 Apr 1998, Manoj Srivastava wrote:
> George> YES they SHOULD! If the /usr/include symlinks are pointed to
> George> /usr/src/kernel-headers-2.0.29 and you install
> George> kernel-source-2.0.32 you MUST change those symlinks to point
> George> to /usr/src/linux-2.0.32/include/...
>
> Please stop spreading misinformation about subjects you know
> little about.
Hmmm, having just come back to compiling a substantial number of kernels
from living mostly in user space for a year and a half, I was unaware that
debian had gone to providing the headers separately. The fact remains,
though, that I really wanted v2.1 headers when I installed v2.1 kernel
sources. I have only run into one program that I have had to recompile
with the v2.1 headers (inetd) but I suspect there would be many
more if I had an SMP system. From the document below, I can see the
reasoning. I had not read it and was going according to the instructions
in the 2.1.x sources when I installed them.
Please see my comment and question after this quoting of the most relavant
text (in my opinion).
> Kernel headers no longer make sense exporting to user space
> (in early days of Linux, that was not true). It is beginning to get
> harder to synchronize the libc and the kernel headers as in the old
> days; now linking with the latest kernel headers may subtly break new
> code since the headers linked with are different from the compiled
> library. In addition, the specter of programs breaking with new
> kernel headers was preventing needed new features from being added to
> the kernel (and damping innovative experimentation in kernel
> development) (see appendix A for details).
>
> Besides, the kernel itself no longer needs /usr/include/linux/*
> at all, so keeping the libc and kernel headers the same aren't
> needed for kernel development.
...[SNIP]
>
> The current solution is a variant of the original, bad,
> symlink solution. The variation is that we link to header files from
> a specific kernel version, namely 2.0.32, which are the headers that
> libc was compiled with. Whereas we used to link to any old kernel in
> the original libc5 symlink, the new libc6 symlink is to
> /usr/src/kernel-header-2.0.32, which holds headers from a *static,
> well known*, *supported*, tested kernel version, and we let the
> kernel-headers package handle architecture dependencies (which it had
> to anyway).
>
[SNIP]
>
> So, libc6-dev depends can now provide 2.0.32 kernel headers
> *for all architectures*, with no messy architecture dependent
> patches, we always have fixed, static, known good headers in
> /usr/include/{linux,asm}, and this is goodness.
>
> This is a working technical solution to having libc
> development package contain/depend on a well known static set of
> kernel headers (insulating the vast majority of programs that are not
> closely tied to kernel version specific internal data structures),
> while allowing the kernel headers to vary from architecture to
> architecture, and still allowing device driver authors from having
> any set of kernel headers they want on the machine through the simple
> artifice of adding a -I flag to the compilation flags.
> Linus> Just to give you some idea of exactly why the includes really
> Linus> can't be handled by simple symlinks: the main problem is
> Linus> version skew. Lots of people want to upgrade their library
> Linus> without affecting the kernel, and probably even more people
> Linus> want to be able to upgrade their kernel without affecting their
> Linus> compilation environment. Right now doing that has been
> Linus> extremely fragile.
>
> Linus> Just to give _one_ example of why the symlinks are bad: NR_OPEN
> Linus> and "fd_set". I have had no end of problems making NR_OPEN
> Linus> larger in the kernel, exactly _because_ of the damn
> Linus> sym-links. If I just make NR_OPEN larger (the right thing to
> Linus> do), the problem is that people with old libraries will now
> Linus> compile against a header file that doesn't match the library
> Linus> any more. And when the library internally uses another NR_OPEN
> Linus> than the new program does, "interesting" things happen.
END OF QUOTED TEXT
Ok fine, so what do I do to get a system done correctly running 2.1.X?
It looks like I, at first, point the symlinks to the kernel source
provided headers. Compile glibc. Create a kernel_headers package. Then use
that kernel_headers until both of the following conditions are met:
1) I see substantial changes in the kernel include files.
2) The kernal becomes relatively stable and I have stopped seeing changes
to the kernel includes in the patches.
Then I build another glibc and kernel_headers?
Ok, I can probably live with that. Am I correct in my understanding that
this is the way Debian is doing it? That you use a stable version of
headers over many versions and only change headers used to compile user
programs possibly when you release new glibc versions?
George Bonser
If I had a catchy quip, it would be here.
http://www.debian.org
Debian/GNU Linux ... the maintainable operating system.
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: