> >So what should it point to? I have had more trouble when some Debian
> >package made it not a symlink and if I tried to compile something
> >which needed correct headers for the version I am using I get very
> >strange errors which are hard to diagnose.
>
> Linus has spoken. /usr/include/{linux,asm} must not be a symlink that
> points to kernel code that is updated. glibc must contain the linux
> and asm files that were used to build glibc and those files must not
> change until you change glibc. glibc must take a copy of the kernel
> headers at glibc build time or (much less desirable) it can symlink to
> a set of kernel headers that are guaranteed to never change.
>
> Having glibc linking to some random set of kernel headers is a recipe
> for disaster. kbuild 2.5 deliberately handles the asm symlink
> differently from the old kbuild system, to detect and correct broken
> installations.
Fair enough. I suggest, though, that you put a similar explanation
into kbuild 2.5 documentation.
T.
-- "hello it's not like i read my mail so that you have where to offer to sell me a giant turnip or anything else thankyou." -tomas szepe <kala@pinerecords.com> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:18 EST