new kernel install. instructions for book

Gerard Beekmans gerard at
Mon Mar 12 22:04:03 PST 2001

On March 13, 2001 01:15 am, Jesse Tie Ten Quee wrote:
> Yo,
> On Tue, Mar 13, 2001 at 12:48:11AM -0500, Gerard Beekmans wrote:
> > Bah, scrap that one. $OLDPWD will of course be set to
> > /mnt/lfs/wherever/kernel/is which will do us no good in chroot.
> *patpats* I though you were going to sleep! :)

Glibc is keeping me up. It's going now so I'll get some sleep and see if it 

> Why not just copy the headers over to $LFS/usr/include/linux|asm and
> forget about /usr/src/linux and all the symbolic links.
> I dunno...i've been thinking about it for a couple of months, perhaps i
> should do a search on the mailing list archives again to remenber why i
> didn't like that idea at first...dunno ;)

A reason not to do that:

imagine /usr/src/linux is a symlink that points to your current kernel 
version (a lot of people have more then one kernel copy lying around when 
upgarding it, just in case a new one doesn't work you have an old one that 
does work). /usr/include/linux|asm point to /usr/src/linux/include/linux|asm

So by simply changing the /usr/src/linux symlink to a new kernel tree all 
subsequent package builds will be using the kernel headers from that new 
tree. If headers of a particular kernel don't work you don't have to remove 
any files from /usr/include/linux|asm and copy new ones to it. Just change 
/usr/src/linux to point to a different tree.

A reason not to do so: apparently (i haven't read this myself yet) Glibc 
suggests that /usr/include/linux|asm contain the same headers that were used 
during the compilation of Glibc. I'm not sure why one suggests that. It will 
be hard to test software against a future 2.5 or 2.6 kernel when the header 
files are always of the one that glibc was installed with. That means 
whenever you upgrade a kernel you would have to recompile Glibc as well. I 
don't particularly like that idea, i've done it the above way (with symlinks 
so include/linux|asm always contain headers that match the kernel that's in 
RAM right now) and never caused problems.

So I guess both ways have their pro's and con's. Which outweigh which for you 
and you can make a decision what to do.

Perhaps this should noted during kernel's install that we don't do as Glibc 
suggests (for above stated reasons) and if user wants to follow Glibc 
(eventhough not everybody fully agrees with it) a few changes need to be made.

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-

Unsubscribe: send email to lfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the lfs-dev mailing list