lkml.org 
[lkml]   [1999]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: toplevel Makefile bug and simple fix


>> Sorry, I still maintain that it's a bug in the Makefiles because the
>> kernel and the "scripts" it comes with should be able to build in
>> it's own self contained directory...
>
>Well, it doesn't. The various helper programs are already not
>self-contained. They already use /usr/include, /lib/libc.so*, etc.
I understand that ("self-contained" might not have been the best
adjective), but IMHO they should at least pick up the correct header files
for my kernel version I'm building without my intervention.. Mostly
because of my point previously WRT building multiple kernels at once...

>>explain below. I think, though, that we're going to have to agree to
>>disagree.
I suppose so...

>No, I think you're misunderstanding the situation. split-include.c
>does *not* use kernel headers. Look again:
>
> #include <sys/stat.h>
> #include <sys/types.h>
>
> #include <ctype.h>
> #include <errno.h>
> #include <fcntl.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <unistd.h>
>
>Note the conspicuous lack of any "#include <linux/*.h>" above.
>split-include.c is just using regular libc headers. One of the libc
>headers is what is needing <linux/*.h>. If split-include.c actually
>included any kernel headers directly, you might have a point.
I fully understand what is happening here.. If I didn't, I wouldn't have
said anything in the first place... I can leave /usr/src/linux pointing to
some kernel source tree, but it won't be the right one for what I'm
building..

>In other words, your problem is not specific to split-include.c. ANY
>program that uses the above set of headers will fail to compile. Which
>makes it a bug in your libc header files.
Yes, I know.. And when I ftp some piece of code over and it needs that to
build, I can put it back... I wouldn't remove /usr/src/linux at all if
-I$(HPATH) was used in the HOSTCC.. I would just leave it pointing to the
source tree of my default kernel knowing that the Makefile will invoke gcc
or whatever with -I$(HPATH) and the header files will be correctly
included... I remove it because I don't want the wrong kernel version
include files to be used during my kernel builds.. Even if it is something
small...

>> I don't see why it should be a big deal just to add -I$(HPATH) to
>> HOSTCC in the Makefile...
>
>Well, to me it's the principle of the thing -- not only do I believe
>that it's not a kernel bug, I also disagree with overloading $(CC) (or
>$(HOSTCC)) with what are really CFLAGS. Makes it hard to substitute
>one compiler in for another. FSF has a policy about this, actually:
But $(CC) already does this... So the point is moot...

I'm not trying to start any arguments here (I sure as hell wasn't expecting
the thread that resulted). I'm just trying to point out what seems to me to
be a minor pain in the ass... Especially for someone like me who has to
build multiple kernel versions..

Cheers...Paul..




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.035 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site