Re: cannot compile 2.1.5 due to /usr/include/linux being in libc5-dev
On Sun, 27 Oct 1996 12:52:32 CST edwalter@students.wisc.edu wrote:
> On Sun, 27 Oct 1996, Philippe Troin wrote:
> > This is a long story and it generated a lot of discussions here.
> > The consensus is that it's better for user-level programs to be compiled with the same set of kernel file than libc was compiled with.
> > Obviously, if you want to compile your own kernel-level stuff that's a problem. But the kernel itself shouldn't look in /usr/include. I wasn't aware that 2.1 was looking here. Hmmm.
>
> Almost every kernel that have looked in (including 2.0.x) looks in
> /usr/include.
>
> Anytime a file needs an include file it it referenced lise this:
>
> #include <linux/whatever.h>
>
> This is /usr/include/linux/whatever.h. It is assumed by Linus,
> et. al., that /usr/include/linux, /usr/include/asm, and
> /usr/include/asm-i386 will all be symlinks to the actual kernel
> source.
Nope. Linus et al. don't assume anything. If you configure the kernel
correctly, it will never have to look up in /usr/include. The -I
passed to gcc ensure that the kernel headers are taken from the
sources, not anywhere else.
> The only solution for me has been to move the offender out of
> the way and temporarily create the expected symlinks while I compile
> the kernel and then put everything back when I am done. I have put
> this in a script since I try to keep up with the 2.1.x kernels and
> have to compile somewhat frequently, but this is still kind of a
> pain. Maybe someone else can tink of some better solution/compromise.
You don't have to do this. There is no problem here :-).
There might be a problem when compiling say en external module. Then
add the good -I lines to the Makefile, and it's fixed.
Phil.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: