new kernel install. instructions for book

Fabio Fracassi f.fracassi at gmx.net
Wed Mar 14 04:03:07 PST 2001


On Wednesday 14 March 2001 01:06, Gerard Beekmans wrote:
> On March 13, 2001 04:53 pm, Brett wrote:
> > Hmm,
> >
> > I hate to butt in, since I haven't been following the thread.
>
> That's ok
>
> > But the "official" word from linus is exactly that.  Don't have
> > /usr/include/[linux,asm] as symbolic links.  Leave the kernel headers
> > which were used to compile glibc in there.  That should solve everything,
> > correct ????
>
> So that pretty much means that whenever you upgrade your kernel you have to
> recompile Glibc. That's a pretty tough upgrade not to mention a lengthy
> procedure.
>
> Sure you can keep old kernel headers in /usr/include/linux|asm (old
> compared to whatever is in /usr/src/linux). Then one day one of the kernels
> have some bug fixes that come with fixed header files which could fix
> compile problems with some package. You can't use those header files
> actually unless you first recompile Glibc with those header files.
>
> So I'm wondering what exact reasons Linus has for suggesting that. And if
> it's just a suggestion (so you don't risc breaking kernel headers when
> running a newer kernel) or something that has to be done. I'd like to know
> the reasons before making the change in the book. It's on the todo list,
> somebody will investigate this (either me or whoever else gets to it
> first).

I think it is a safety statement, along the same line like Linus says that 
ecgs-what-do-I-know is still the "official" kernel compiler.
It is something like, this works for sure, I can't proove that the other one 
will.
I know that at least SuSe has(had?) it the same way as we do, with symlinks.
Since I have never heard of any problems with this (neither here nor in SuSe 
times), I belive we should stick to it.

Fabio













-- 
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 mailing list