Burt,

I also know this is *HOW* it was supposed to work, I do believe I got
flamed pretty heavily on asking that question on the lkml at one time!
:)  Those headers are definitely supposed to be linked to glibc, not
your kernel version.


On Wed, 2004-09-29 at 11:55, Burt Holzman wrote:

> ---------------------- Information from the mail header -----------------------
> Sender:       Mailling list for Scientific Linux users worldwide
>               <[log in to unmask]>
> Poster:       Burt Holzman <[log in to unmask]>
> Subject:      Re: Problem with kernel dev after upgrading 301 to 302
> -------------------------------------------------------------------------------
>
> csieh wrote:
> >>It's always been that way.  As far back as RedHat 7.  Beyond that, I don't
> >>know because I used to use Slackware.  If you look at the
> >>glibc-kernheaders version number, you'll see they don't even match the
> >>initial kernel that comes with that distribution.  Not your fault.
> >>RedHat's been doing this since I started using RedHat many moons ago.
>
> > I guess I have updated kernels many times and then rebuilt them and not
> > had to make these links.
>
> I also haven't had this problem and have rolled many, many kernels over
> the years.  And I don't advise to follow Ken's procedure:
>
> Applications in userland should not link against the headers in the
> kernel source.  What is important for them is the kernel headers that
> glibc was linked against, which is why that is what's included and also
> why it probably doesn't match your running kernel.  I seem to recall
> quite a few rants on lkml about this.
>
> - B