NVIDIA and kernel.h

[tobemi]

I am having problems installing my Nvidia driver for Mandrake 10.0. My graphics card is a GeForce ti200.

I have installed the kernel-source files from X and now get the error "cant find kernel.h". I checked the usr/src/include library and found the source RPM. Furthermore I have a broken link in my usr/src/linux library.

Should the RPM be unpacked or am I missing something??

I appreciate any help on the subject since i am new to Linux and really want to learn.

[je_fro]

/usr/src/linux is a symbolic link to your kernel source, which it appears that you do not have. I don't know what you mean about installing source from X, because i doubt they have any kernel source at all.
Read some manpages:
man man
man ln
man tar
...

[Dark Ninja]

You need to have the /usr/src/linux symbolic link point to /usr/src/linux-2.x.x directory, which is what will allow the NVIDIA drivers to find the kernel.h. Now, I know in Gentoo, I already had the kernel source files downloaded and in the /usr/src/linux-2.6.6 location, so all I had to do was:

ln -s /usr/src/linux-2.6.6 /usr/src/linux

However, all you may need to do in Mandrake is use the package installation program and install the kernel sources. (kernel source files, kernel source...?)

[tobemi]

Thank you both for your help .. I got it working now

[bwkaz]

Originally posted by je_fro
/usr/src/linux is a symbolic link to your kernel source, Originally posted by Dark Ninja
You need to have the /usr/src/linux symbolic link point to /usr/src/linux-2.x.x directory, which is what will allow the NVIDIA drivers to find the kernel.h. NO NO NO!

/usr/src/linux is NOT the right place to look for the current kernel's header files! Of course, the nVidia compilation process only looks there if the right place to look doesn't exist, but still.

The right place to look is /lib/modules/<version of the kernel that you're compiling for>/build/include (/lib/modules/X.Y.Z/build is a symlink to the sources for kernel X.Y.Z; it's created when you run make modules_install).

You got it working now, but you were operating under misguided help (sorry je_fro and Dark Ninja, but that symlink business has been unnecessary for a few years now, yet somehow people still think they need to create it... and what's really dumb is packages like cdrtools that use it for userspace, which just makes the problem worse...).

[GaryJones32]

Originally posted by bwkaz
NO NO NO!

/usr/src/linux is NOT the right place to look for the current kernel's header files!

This was an old workaround because distributions had picked up on the glibc developers use of symlinks
/usr/include/asm -> /usr/src/linux/include/asm
/usr/include/linux -> /usr/src/linux/include/linux
those links required that people not update /usr/src/linux
now that those problematic links are no longer a part of distributions
there is no valid reason not to go back to updating the link /usr/src/linux
accept to avoid getting yelled at by the misinformed

[je_fro]

Why is it then that if I remove the /usr/src/linux symlink, nothing compiles?

[bwkaz]

Originally posted by je_fro
Why is it then that if I remove the /usr/src/linux symlink, nothing compiles? Because whatever you're compiling is broken. :D

Kernel modules need the raw headers from the kernel they'll be loaded into. Userspace should never be using raw kernel headers (the fact that it worked up until 2.6 was an unintentional side effect).

The raw headers for a specific kernel version are in /lib/modules/<version>/build/include/{linux,asm}. The sanitized headers that userspace needs are in /usr/include/{linux,asm}. /usr/src/linux does not appear in that list, therefore, it is not needed.

I put my kernels in my home directory (which allows me to compile them as me, not root, also). My system has no /usr/src/linux or /usr/src/linux-<version> at all; it's not needed by proper packages.

(And if /usr/src/linux happens to be 2.6, then cdrtools 2.00.3 won't compile, for one. In fact, it shouldn't be including from /usr/src/linux anyway, but it is, and it breaks against 2.6. If /usr/src/linux doesn't exist, then the compile goes great.)

Originally posted by GaryJones32
now that those problematic links are no longer a part of distributions there is no valid reason not to go back to updating the link /usr/src/linux But what's the point of doing it? The kernel installation creates a usable symlink for you (see above: /lib/modules/$(uname -r)/build). My kernels don't live in /usr/src anyway.

And see this for what happens when you compile as root:

True story: gconfig removed root folder... (http://seclists.org/lists/linux-kernel/2004/Jan/3956.html)

Also see the debian-user list archives (http://lists.debian.org/debian-user/2001/02/msg04301.html).

[GaryJones32]

Originally posted by bwkaz

But what's the point of doing it?

Ahhhhh i think when you say NO NO NO

then by definition logically you have to show a reason to NOT do it.....
and we haven't seen one.

[QOUTE]
And if /usr/src/linux happens to be 2.6, then cdrtools 2.00.3 won't compile, for one[/QUOTE]
I just made the symlink /usr/src/linux pointing to my current kernel source directory
linux-2.6.3 -- something i don't normally do.
then i compiled cdrtools-2.00.3 with:
make INS_BASE=/usr DEFINSUSR=root DEFINSGRP=root
and it worked flawlessly
CONCLUSION: You are just making this crap up as you go along to suport your "RULE" you insist on as etched in stone that i have poined out is an outmoded rule at this point.
this is one of those times where the textbook definition of neurosis comes to mind.
Please don't post stuff here you don't actually know is true !

[bwkaz]

If you would reread my post, you would see that the NO NO NO was replying to the comment about "the nvidia drivers will find the kernel sources in /usr/src/linux". I was quoting the other post also, but only for later discussion (why keeping the symlink is not necessary).

The nVidia drivers will find the kernel headers there, but (I'll say this again, hopefully you'll hear it this time) only if the proper location (/lib/modules/XXX) is not found.

The reason is, /usr/src/linux is NOT the correct place for those drivers (or anything else) to look, in any case at all. External kernel modules (like nVidia) use /lib/modules, and userspace uses /usr/include. Nothing should use /usr/src/linux, and rightly so. It's not guaranteed to not change (like /usr/include is -- at least until you change glibc), and it's not guaranteed to be the currently running kernel (like /lib/modules/$(uname -r)/build is). It's not even guaranteed to exist.

----

All I know about cdrtools 2.00.3 was that the copy I had, against the kernel sources I had, did not compile in libscg, because the kernel headers introduced an incompatibility. I think the cdrtools maintainer was complaining to lkml about it, so perhaps it's been fixed in later kernels (although the stock answer on lkml ALWAYS seems to be "don't use kernel headers in userspace", and being the developers, they're automatically right when it comes to policy regarding their includes). I had 2.6.1-rc1 in /usr/src/linux at the time, so it's possible that <scsi/scsi.h> has been changed.

Actually, I still do have 2.6.1-rc1 in /usr/src/linux. And checking again, it still breaks:

$ tar xjf /usr/src/sources/c/cdrtools-2.00.3.tar.bz2
$ cd cdrtools-2.00.3/libscg
$ make INS_BASE=/usr DEFINSUSR=avatar DEFINSGRP=root
<configure output>
<missing dependency files>
==> MAKING DIRECTORY "OBJ/authenticamd-linux-cc"
==> MAKING DEPENDENCIES "OBJ/authenticamd-linux-cc/rdummy.d"
==> MAKING DEPENDENCIES "OBJ/authenticamd-linux-cc/scsihelp.d"
==> MAKING DEPENDENCIES "OBJ/authenticamd-linux-cc/scgtimes.d"
==> MAKING DEPENDENCIES "OBJ/authenticamd-linux-cc/scsierrs.d"
==> MAKING DEPENDENCIES "OBJ/authenticamd-linux-cc/scgsettarget.d"
==> MAKING DEPENDENCIES "OBJ/authenticamd-linux-cc/scsiopen.d"
==> MAKING DEPENDENCIES "OBJ/authenticamd-linux-cc/scsihack.d"
==> MAKING DEPENDENCIES "OBJ/authenticamd-linux-cc/scsitransp.d"
==> MAKING DIRECTORY "../libs/authenticamd-linux-cc"
==> COMPILING "OBJ/authenticamd-linux-cc/scsitransp.o"
==> COMPILING "OBJ/authenticamd-linux-cc/scsihack.o"
In file included from scsi-linux-sg.c:69,
from scsihack.c:127:
/usr/src/linux/include/scsi/scsi.h:203: error: parse error before "u8"
/usr/src/linux/include/scsi/scsi.h:203: warning: no semicolon at end of struct o
r union
/usr/src/linux/include/scsi/scsi.h:204: warning: data definition has no type or
storage class
/usr/src/linux/include/scsi/scsi.h:205: error: parse error before "_r2"
/usr/src/linux/include/scsi/scsi.h:205: warning: data definition has no type or
storage class
/usr/src/linux/include/scsi/scsi.h:206: error: parse error before "block_desc_le
ngth"
/usr/src/linux/include/scsi/scsi.h:206: warning: data definition has no type or
storage class
/usr/src/linux/include/scsi/scsi.h:207: error: parse error before "density"
/usr/src/linux/include/scsi/scsi.h:207: warning: data definition has no type or
storage class
/usr/src/linux/include/scsi/scsi.h:208: error: parse error before "number_blocks
_hi"
/usr/src/linux/include/scsi/scsi.h:208: warning: data definition has no type or
storage class
/usr/src/linux/include/scsi/scsi.h:209: error: parse error before "number_blocks
_med"
/usr/src/linux/include/scsi/scsi.h:209: warning: data definition has no type or
storage class
/usr/src/linux/include/scsi/scsi.h:210: error: parse error before "number_blocks
_lo"
/usr/src/linux/include/scsi/scsi.h:210: warning: data definition has no type or
storage class
/usr/src/linux/include/scsi/scsi.h:211: error: parse error before "_r3"
/usr/src/linux/include/scsi/scsi.h:211: warning: data definition has no type or
storage class
/usr/src/linux/include/scsi/scsi.h:212: error: parse error before "block_length_
hi"
/usr/src/linux/include/scsi/scsi.h:212: warning: data definition has no type or
storage class
/usr/src/linux/include/scsi/scsi.h:213: error: parse error before "block_length_
med"
/usr/src/linux/include/scsi/scsi.h:213: warning: data definition has no type or
storage class
/usr/src/linux/include/scsi/scsi.h:214: error: parse error before "block_length_
lo"
/usr/src/linux/include/scsi/scsi.h:214: warning: data definition has no type or
storage class
/usr/src/linux/include/scsi/scsi.h:221: error: parse error before "u8"
/usr/src/linux/include/scsi/scsi.h:221: warning: no semicolon at end of struct o
r union
make[1]: *** [OBJ/authenticamd-linux-cc/scsihack.o] Error 1
make[1]: Leaving directory `/home/bilbo/cdrtools-2.00.3/libscg'
make: *** [all] Error 2 Looks like it's pretty well broken to me...

Besides, I do not "make up" technical details, and I never have.

Regarding the neurosis comment, must you resort to name-calling? Good grief. :rolleyes:

[GaryJones32]

please forgive the length of this post -- this is a very complex issue -- if no one wants to go there with me that's cool (duh)! (hit that back button now) no normal three word internet post here.

Originally posted by bwkaz
[b]ALWAYS seems to be "don't use kernel headers in userspace"

yes but no one here was talking about user space....
the guys were compiling a kernel module !
that's about as not user space as it gets.
but it can be sucessfully argued that cdrtools is userspace
but you interjected that out of the blue as having something to do with /usr/src/linux


/usr/src/linux/include/scsi/scsi.h:203: error: parse error before "u8"

this is not an easy question -- i guess most people consider the fact that cdrtools tries to use currently running kernel
headers a mistake on their part...
afterall no one else i know of does it..
I think i'm not qualified to say -- i mean the guy it trying to use the currently running scsi emulation module yes ???
frankly i can't figure out what symbols are in glibc and what say of a compiled module like scsi is usable or not-usable?
perhaps the guy that writes cdrtools does know what he can use and what he can't ???
the guy obviously doesn't like Linux so possibly he is being a contrarian....
so either way i think it makes more sense just to hack his makefile if you want, than to say /usr/src/linux is wrong...
if we use your adage -- the developers are always right then--
cdrtools requires headers from the currently running kernel.
if it's just that the guy is being a jerk that doesn't have anything to do with /usr/src/linux he can just switch to
/lib/modules/`uname -r`/ easy enough if he wants.
as a matter of fact proper compile of other non-Linux programs (iproute2 comes to mind) depends on the symlink /usr/src/linux !
from cdrtool perspective for a moment
this is from the README.Linux of cdrtoos
**** Never change the content of /usr/src/linux/include/scsi/sg.h without properly recompiling the kernel. Cdrecord depends on the fact that the value of the define SG_BIG_BUFF uses the same value as the actual
kernel.
now it may be that this value is unchanging but given the fact that user space includes are just old kernel versions how do programmers know ???????? is this value defined in glibc version of the headers ?? I bet not.. the whole thing is very confusing.
This leads to the notion expressed by the cdrtools developers and you can see their point
The main problem with Linux is a result of the fact that a lot of people believe that it is possible to replace the Kernel with a different version without creating problems with the interfaces to the applications.
or on the flipside by using static sanitized includes we make the actual kernel unusable by anyone. We make the API a safe subset -- that seems kind of funky.
bottom line there shoudln't be user and kernel space kernel headers and we sholdn't be upgrading the kernel the way we do.
Basically the Unix developers already think generally that Linux is a bunch of thrown together inconsistent crap....
not an OS but rather just a kernel with lord only knows what attached to it.
and one of the reasons no doubt is the confusion around user space kernel and kernel space kernel headers.
glibc not being recompiled when the kernel is upgraded even though it should be.
I'm afraid it might be perpetuating the confusion and not fixing it by implying /usr/src/linux is somehow "user space"
although from a historical perspective very early linux distributions likely had /usr/includes linked to /usr/src/linux ?????
but they were gotten to thru /usr/includes so /usr/src/linux is not a problem there just a convention.
seems like abitrary rules about not using /usr/src/linux
the way it is used today
when that is what the sun developers rely on is absurd.
especially if we are just trying to get them into user space where we think they belong
I don't think any simple rules are going to fix such a complex problem.

Regarding the neurosis comment, must you resort to name-calling? Good grief. :rolleyes:

this is not name calling in any way and i'm sorry if it seemed that way. the text book definition of a simple neurosis is a "Rule" that is insisted apon with no valid underlying logical reason or a reason whos validity is past.
-- all of us have a fairly large body of this type of stuff to weed out yes -- i know i do
you don't seem to be engaging the issue but rather just proclaiming a rule -- seems a little odd
seems Linux above most all things is about freedom not rules and computer programming is about logic in the strictest of terms and is never about anything else.

[bwkaz]

Originally posted by GaryJones32
yes but no one here was talking about user space....
the guys were compiling a kernel module !
that's about as not user space as it gets.
but it can be sucessfully argued that cdrtools is userspace
but you interjected that out of the blue as having something to do with /usr/src/linux I think somebody wasn't following this thread properly, or something.

I "interjected cdrtools out of the blue" to show why having /usr/src/linux AT ALL is harmful. The discussion was on the nVidia kernel module, yes. People were claiming that it looked in /usr/src/linux, so the original poster needed /usr/src/linux to point at his currently running kernel.

That is not true, unless the OP's kernel installation was broken (by not including the /lib/modules/<kernel version>/build symlink). nVidia uses /lib/modules/blah blah blah if it can, and nVidia should be commended for doing the right thing.

My original post was saying that /usr/src/linux does NOT need to point at your current kernel for nVidia to work properly. The cdrtools comment was posted as an example of something that broke when /usr/src/linux did exist (rather than when it didn't; je_fro claims that stuff breaks when it doesn't exist).

if we use your adage -- the developers are always right OK, now I know you don't read my posts closely enough.

That is NOT what I said at all.

I said "they're automatically right when it comes to policy regarding THEIR includes", not "they're automatically right always"! The developers' wishes about who can use their include files are ALWAYS to be followed. The developers who claim that their program needs specific kernel headers, OTOH, need to FIX their program instead of using the cop-out of "just use the current kernel headers". For one possible way they could do this, keep reading just a little bit.

this is from the README.Linux of cdrtoos
**** Never change the content of /usr/src/linux/include/scsi/sg.h without properly recompiling the kernel. Cdrecord depends on the fact that the value of the define SG_BIG_BUFF uses the same value as the actual kernel. How about this:

The scsi driver should, instead, export this value in a file in sysfs somewhere. Then, cdrtools can read it AT RUNTIME, and use the current kernel's value. That way, upgrading your kernel will NOT break it (according to that README, any kernel upgrade has the potential of breaking it, because cdrtools hardcodes the value it needs). Hardcoding values that can change means that as soon as you recompile a kernel, you need to recompile the world along with it, to keep the changes synchronized -- and if that's really the way you claim we should all work, then why do the kernel developers stay backward compatible in the first place? (see below)

now it may be that this value is unchanging but given the fact that user space includes are just old kernel versions how do programmers know? That's the kind of argument I hear from a lot of people that don't understand sanitized headers at all.

The headers for userspace are NOT just "old kernel headers" (they were when 2.4 was in use, but that was wrong too; now who's working off outdated information? :p). They're supposed to be sanitized headers, that keep pace with the current kernel's features (so that glibc, and therefore the rest of userspace, can use them), but also need to keep some backward compatibiltiy so that userspace doesn't break. Sometimes that's impossible, but it's worked fairly well for the linux-libc-headers project (hereinafter referred to as LLH to reduce typing), which was put together for the PLD distro, and LFS also uses this package for their userspace headers.

These are the headers cdrtools should be using. If the value that they need changes, then they should be detecting it AT RUNTIME, not at compile time. If the value they need doesn't change, but isn't in the sanitized headers, then they should be including that value in a private header somewhere inside cdrtools.

is this value defined in glibc version of the headers? I bet not. Actually, it is, in Fedora's headers at least (I don't have a copy of LLH, so I can't check those; when I built this system, LLH didn't yet exist):

In /usr/include/scsi/sg.h:

#define SG_SCATTER_SZ (8 * 4096)

#define SG_DEF_RESERVED_SIZE SG_SCATTER_SZ

#define SG_BIG_BUFF SG_DEF_RESERVED_SIZE Now I don't know if that matches all kernels, but if not, it should be exported via sysfs (and a patch to the scsi driver to make it do that would be trivial) so that it can be detected at runtime, independent of constants in header files.

The main problem with Linux is a result of the fact that a lot of people believe that it is possible to replace the Kernel with a different version without creating problems with the interfaces to the applications. Why should it not be? The kernel is ALWAYS backward compatible w.r.t. syscalls and structures passed back and forth from userspace; that only leaves constants like this one. If a constant isn't really constant, then it should be detected AT RUNTIME. If it is really constant, then declare it privately and forget about it.

The basic problem is that everybody's too lazy to do things the RIGHT way. Instead, they just use cop-outs like "use raw headers, even when that's impossible because my program breaks".

or on the flipside by using static sanitized includes we make the actual kernel unusable by anyone. We make the API a safe subset I think you don't understand sanitized headers.

They are NOT "a safe subset" of the API. They closely follow the features from the current kernel, but keep the ability to be used from userspace.

And if your beef with sanitized headers is that they don't change, that's not a good reason either. They SHOULDN'T change, unless glibc changes. Because those headers are the interface to the kernel through glibc, you can't leave glibc out of the picture.

For example, say the kernel defined sys_dostuff() syscall number 500, which takes the address of a struct info, and glibc is compiled against that kernel. The contents of struct info are fixed to glibc, not the kernel, because the REAL interface to the kernel is the syscall NUMBER, not name. If the kernel later changes that sys_dostuff, they'll rename the original one sys_dostuffold() (or something), and give sys_dostuffold() its old syscall number (500) so that the old glibc will still be calling into the right syscall. They'll also define a new struct info, and rename the original one to struct info_old (or something) in their headers (so that sys_dostuffold() can use it).

New glibc compiles will see that dostuff() is now syscall 501, and use that instead. They'll get the new struct info also. But since the "current" (old) glibc is still calling the old syscall number, it'll still be passing the old structure (because that's what its headers have). Which is great, both systems work.

Now, if you start to use raw kernel headers from the kernel that has the second syscall version from your program, your userspace code will create a struct info (with the new members), and fill it. Then it'll call glibc's dostuff() function, which will invoke syscall number 500 (which SHOULD be taking a struct info_old). That's why the stuff that userspace includes NEEDS to be synchronized with glibc, not the kernel.

I'm afraid it might be perpetuating the confusion and not fixing it by implying /usr/src/linux is somehow "user space" But that's NOT WHAT I SAID. I said it didn't even need to EXIST (and it caused a problem when it did, if a certain kernel was there).

[blackhawk714]

this is pretty cool. Alright you two ... READY ... FIGHT!
lol
:D :D ;)

[hard candy]

No byteing!!! :)

[je_fro]

je_fro@gentoo je_fro $ ls -l /usr/src/
lrwxrwxrwx 1 root root 11 May 27 16:16 linux -> linux-2.6.6
drwxr-xr-x 19 root root 1248 Jun 12 00:34 linux-2.6.6

I'm going to keep it like that until it breaks something...that's all I know.
:)

[GaryJones32]

Originally posted by bwkaz
I said it didn't even need to EXIST (and it caused a problem when it did, if a certain kernel was there).

The Makefile of cdrtools caused problems
not /usr/src/linux and /usr/src/linux needs to be there for iproute2 and other non linux kernel ports that use the same Makefile system.


It is very easy to sit back and say Joerg Schilling is a lazy programmer who doesn't know what he is doing.
cdrecord compiles and functions properly on
32 different operating systems
yes 32 that's not a mistype
it works on Linux alone over 13 different architectures.
and fully supports 194 different cd drives
yes 194

so we should all cry a river about how he doesn't use our headers right -- who does he think he is ??????
Linux is all that matters !!!
OK i quit now
and thanks for hashing that out about glibc with me by the way
it did help me understand better.


They're supposed to be sanitized headers, that keep pace with the current kernel's features

i dont get how something that never changes can "keep pace"
with anything ??? esoecially features that haven't been dreamed up yet ????? but i will concede this is my problem.

I quit with a quote from Rick Moen on this issue
which is what i was saying in the first place
Rick helped plan the LINC Expo (which evolved into the first LinuxWorld Conference and Expo, in San Jose).
He's written and edited for IDG/LinuxWorld, SSC, and the USENIX Association; and spoken at LinuxWorld Conference and Expo and numerous user groups.
so I'm going to take his word on this.
" to recap: If your distro has been brought up to modern standards, your playing games with /usr/src/linux (and compiling kernels there)
won't hurt anything."
so if it won't hurt anything and we still encounter scripts everyday with:

check_version_h() {
if [ ! -f "${ROOT}/usr/src/linux/include/linux/version.h" ]
then
eerror "Please verify that your /usr/src/linux symlink is pointing"
eerror "to your current kernel sources, and that you did run:"
eerror
eerror " # make dep"
die "/usr/src/linux symlink not setup!"
fi
}


Make the *&^% link if it helps you compile the stupid NVIDIA driver !!!!!!

[bwkaz]

Originally posted by GaryJones32
Make the *&^% link if it helps you compile the stupid NVIDIA driver !!!!!! BUT IT WON'T (or at least, it shouldn't).

That was what I've been saying all along. nVidia does the right thing, and does NOT look in /usr/src/linux (unless /lib/modules/whatever doesn't exist, and at that point, the user has likely already screwed up their kernel -- for example, by not configuring it to support modules -- so nVidia won't work in any case).

The symlink to check is /lib/modules/$(uname -r)/build, not /usr/src/linux.

[janet loves bill]

echo "--kernel-include-path=[KERNEL INCLUDE PATH]"
echo " The directory containing the kernel header files that should be"
echo " used when compiling the NVIDIA kernel module. When not"
echo " specified, the installer will use '/lib/modules/\`uname"
echo " -r\`/build/include/', if that directory exists. Otherwise, it"
echo " will use '/usr/src/linux/include'."
echo ""
echo "--kernel-install-path=[KERNEL INSTALL PATH]"
echo " The directory in which the NVIDIA kernel module should be"
echo " installed. The default value is either '/lib/modules/\`uname"
echo " -r\`/kernel/drivers/video' (if '/lib/modules/\`uname -r\`/kernel'"
echo " exists) or '/lib/modules/\`uname -r\`/video'."

I yanked this from nVidia driver...Version 4496 which is the one I use because it is the best one for my box........your mileage may vary.........but I digress............maybe this will answer any other questions the some may have.........

[GaryJones32]

Originally posted by bwkaz

The headers for userspace are NOT just "old kernel headers" (they were when 2.4 was in use, but that was wrong too; now who's working off outdated information? :p). They're supposed to be sanitized headers, that keep pace with the current kernel's features (hereinafter referred to as LLH to reduce typing), which was put together for the PLD distro, and LFS also uses this package for their userspace headers.



Current stable Linux From Scratch version 5.1.1
uses kernel headers straight from linux-2.4.26
package

[bwkaz]

Originally posted by GaryJones32
Current stable Linux From Scratch version 5.1.1
uses kernel headers straight from linux-2.4.26
package That's because the current stable LFS (version 5.1.1) still uses kernel 2.4. As such, it is still broken w.r.t. kernel headers (but it works with 2.4, so nobody there is going to change it).

LFS 6 (current Subversion checkouts) will use kernel 2.6 plus NPTL, hotplug, and udev. And the book that's stored in Subversion head right now (what was CVS HEAD) uses the linux-libc-headers package.