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