Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: Using kernel headers that are not for the running kernel | Date | Thu, 17 Jun 2004 17:04:30 -0700 |
| |
> I have a little distro that I am trying to upgrade to 2.6.x.
Okay.
> The problem is that when I use the headers for 2.6.x, glibc 2.2.5 won't > compile. Eventually I want to upgrade glibc/gcc, but not at the moment. > If I use the headers from 2.4.26 for the system, but just compile the > 2.6.7 kernel, things do compile fine for everything.
You should not be using the kernel headers to compile glibc.
> This distro is small, and I can rebuild the entire thing in about 90 mins, > so if I change the kernel (or really anything that has other deps), I just > rebuild the entire thing to make sure everything is in sync.
The running kernel should not be in sync with glibc.
> I see that a lot of distros use a separate package for the kernel headers, > which do not necessarily coincide with the running kernel.
Right, there is no reason they should.
> I am wondering what (if any) are the side effects of doing this are, > especially when the kernel versions are so different. I was thinking that > there may be issues with some progs if the prototypes for certain kernel > functions weren't the same. However people are doing it and it does seem > to work, but I am wondering how it fends for stability.
It creates a stable system. Things become much less stable if you mess around with all of userspace just because the kernel changes. There is no reason user space should be in sync with the running kernel. User space should be stable.
The later the kernel headers you use in user space, the less compatability you will have with earlier kernels. A program compiled with 2.4.26 header files should work with 2.6.x, but not vice versa. When new kernel interfaces are added, the old ones are retained to keep compatability with user space, but programs compiled against the newer headers may fail to work with older kernels that lack the newer interfaces. Of course, user space programs compiled against the older kernel header files can't get the advantages of the newer interfaces.
The kernel-user interface is supposed to stay stable, so you shouldn't need to make significant user space changes when you upgrade the kernel. Only specific applications that need to get specific new features that require changes to the kernel-user interface need to change. It has been a very long time since compiling user space programs against the header files for the kernel you happened to be running was considered good practice.
DS
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |