Messages in this thread | | | From | paulsch@us ... | Date | Mon, 8 Nov 1999 17:49:10 -0500 | Subject | Re: 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/
| |