new kernel install. instructions for book
gerard at linuxfromscratch.org
Mon Mar 12 22:04:03 PST 2001
On March 13, 2001 01:15 am, Jesse Tie Ten Quee wrote:
> 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.
-*- If Linux doesn't have the solution, you have the wrong problem -*-
Unsubscribe: send email to lfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the lfs-dev