Re: cannot compile 2.1.5 due to /usr/include/linux being in libc5-dev
> On Sun, 27 Oct 1996, Philippe Troin wrote:
>
>
> Almost every kernel that have looked in (including 2.0.x) looks in
> /usr/include.
This is wrong.
>
> Anytime a file needs an include file it it referenced lise this:
>
> #include
>
> 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.
I just checked the source tree for 2.0.21, and what it does is sets a
variable HPATH in the makefile to be ${TOPDIR}/include, where ${TOPDIR}
is the current working directory from which make was run. It then adds
-I${HPATH} to the CC variable, so that if I had my Linux source tree in
/var/tmp/linux (which I do), it would search /var/tmp/linux/include/linu
x for whatever.h before even looking in /usr/include/linux. It is my
understanding that the kernel sources are designed to be as independant
of the system header files as possible, and tries to make no
assumptions about what, or where, the standard system headers are.
> 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.
I haven't gone to 2.1 yet (the horror stories of device drivers
crashing because of the memory management reorganization scare me), so
I don't know if things have changed in this regard.
>
> Erv
--
Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: cannot compile 2.1.5 due to /usr/include/linux being in libc5-dev
On Sun, 27 Oct 1996 12:52:32 CST [EMAIL PROTECTED] 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 > > 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 [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: cannot compile 2.1.5 due to /usr/include/linux being in libc5-dev
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 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. 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. Erv ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ ==-- _ / / \ ---==---(_)__ __ __/ / /\ \ - [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / / /_/\ \ \ - [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ /__\ \ \ - [EMAIL PROTECTED] http://www.linux.org \_\/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: cannot compile 2.1.5 due to /usr/include/linux being in libc5-dev
On Sun, 27 Oct 1996 17:38:12 +1100 Hamish Moffatt ([EMAIL PROTECTED] rmit.EDU.AU) wrote: > I mentioned previously that it's very difficult to compile modules > and things on Debian because /usr/include/linux is from libc5-dev, > and hence contains old version.h, and doesn't contain modversions.h. > This problem is even worse in that you cannot compile kernel 2.1.5 > on Debian; it looks for several files in /usr/include/linux > that are not there. > > Why is /usr/include/linux not part of the kernel-headers or > kernel-source package? I thought it was mandatory to have either > one of these installed. 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. Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
cannot compile 2.1.5 due to /usr/include/linux being in libc5-dev
I mentioned previously that it's very difficult to compile modules and things on Debian because /usr/include/linux is from libc5-dev, and hence contains old version.h, and doesn't contain modversions.h. This problem is even worse in that you cannot compile kernel 2.1.5 on Debian; it looks for several files in /usr/include/linux that are not there. Why is /usr/include/linux not part of the kernel-headers or kernel-source package? I thought it was mandatory to have either one of these installed. hamish -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
