lkml.org 
[lkml]   [2004]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: Using kernel headers that are not for the running kernel
    Date

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

    \
     
     \ /
      Last update: 2005-03-22 14:03    [W:0.034 / U:1.196 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site