[PATCH] use correct include dir for build tools

[PATCH] use correct include dir for build tools

[Robert Read]

Linus,

Please apply one line patch to the top level Makefile.  This points
the build tools at the correct linux include dir.

diff -ru linux/Makefile linux-makefile/Makefile
--- linux/Makefile      Wed Feb 21 16:54:15 2001
+++ linux-makefile/Makefile     Thu Feb 22 12:34:57 2001
@@ -16,7 +16,7 @@
 FINDHPATH      = $(HPATH)/asm $(HPATH)/linux $(HPATH)/scsi $(HPATH)/net
 
 HOSTCC         = gcc
-HOSTCFLAGS     = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
+HOSTCFLAGS     = -I$(HPATH) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
 
 CROSS_COMPILE  =

Re: [PATCH] use correct include dir for build tools

[Matthew Kirkwood]

On Thu, 22 Feb 2001, Robert Read wrote:

> Please apply one line patch to the top level Makefile.  This points
> the build tools at the correct linux include dir.

Or please don't, it's incorrect.

It breaks cross-compiling, and just generally wrong.  If your
system won't build without this, it's broken.

Matthew.

Re: [PATCH] use correct include dir for build tools

[Alan Cox]

>  FINDHPATH      = $(HPATH)/asm $(HPATH)/linux $(HPATH)/scsi $(HPATH)/net
>  
>  HOSTCC         = gcc
> -HOSTCFLAGS     = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
> +HOSTCFLAGS     = -I$(HPATH) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer

That seems odd. Which build tools need to find kernel includes for this kernel
not the standard C includes

Re: [PATCH] use correct include dir for build tools

[Robert Read]

Ok, my bad, I forgot about cross-compiles. The problem was
scripts/split-include.c includes errno.h, which requires linux/errno.h
to exist, and I thought it would be better to use the current kernel's
version, rather than the system version. I guess not.

robert


On Thu, Feb 22, 2001 at 10:28:58PM +0000, Alan Cox wrote:
> >  FINDHPATH      = $(HPATH)/asm $(HPATH)/linux $(HPATH)/scsi $(HPATH)/net
> >  
> >  HOSTCC         = gcc
> > -HOSTCFLAGS     = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
> > +HOSTCFLAGS     = -I$(HPATH) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
> 
> That seems odd. Which build tools need to find kernel includes for this kernel
> not the standard C includes
> -
> 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/

Re: [PATCH] use correct include dir for build tools

[Mike Castle]

On Thu, Feb 22, 2001 at 02:40:55PM -0800, Robert Read wrote:
> Ok, my bad, I forgot about cross-compiles. The problem was
> scripts/split-include.c includes errno.h, which requires linux/errno.h
> to exist, and I thought it would be better to use the current kernel's
> version, rather than the system version. I guess not.

Oh no.  Definitely not.

Linus went on a tirade not too long ago about that.  You can search the
kernel archives for the details and long heated threads.  But it comes down
to this:

For user space compiling, the kernel include files should be those that
libc was built against.

For kernel space compiling, the kernel include files should be those that
the components will link against (static or modules).

So, theoretically, a package that has both components should take care to
do the proper includes.  But that's it.

(libc does usually take care to be able to build against a later kernel
version than you're running on, and determine at run time what features may
or may not be there, so one could have a 2.4.2 kernel handy to build libc
against while still running a 2.2.18 kernel.  Theoretically.)

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [PATCH] use correct include dir for build tools

[Thomas Dodd]

Mike Castle wrote:
> (libc does usually take care to be able to build against a later kernel
> version than you're running on, and determine at run time what features may
> or may not be there, so one could have a 2.4.2 kernel handy to build libc
> against while still running a 2.2.18 kernel.  Theoretically.)

Red Hat did that for glibc-2.1.9 and glibc-2.2 in RHL-7.0.
Hundreds have complaind about /usr/include/linux
not being a sym link to /usr/src/linux/include/linux.
The kernel headers for glibc are form a pre 2.4.0 kernel
and should probably be updated along with a new glibc
built against the new headers.
I've had no problems with it so far, been running since the
pinstripe beta release.

	-Thomas