Messages in this thread | | | From | Peter Samuelson <> | Date | Mon, 8 Nov 1999 13:56:42 -0600 (CST) | Subject | Re: toplevel Makefile bug and simple fix |
| |
[paulsch@us.ibm.com] > 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 don't have a /usr/src/linux directory, so yeah, I do have dangling > symlinks /usr/include/{linux,asm} which prevent it from building... > That's not the point... I'm not going to argue whether > /usr/include/{linux,asm} should be symlinks or real directories.. > It's irrelevent to this simple problem..
No, it's very relevant. The dangling symlinks are broken. I'll explain below. I think, though, that we're going to have to agree to disagree.
> split-include.c, which is where the build dies if there is no > /usr/include/linux (be it a symlink, real directory or whatever), > should use the header files for the kernel that it came with.. i.e. > It should get the proper header files from > {my_kernel_src_dir}/include/linux... Not from /usr/include/linux > which is a symlink into /usr/src/linux/include/linux which who knows > what kernel version is in /usr/src/linux...
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.
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.
> Say I'm building several kernel source trees and I have them all in > /usr/src... Let's say in /usr/src I have the kernel source dirs > linux-2.0.xx, linux-2.2.xx, and linux-2.3.xx.. First, I don't want > to have to muck with making /usr/src/linux a symlink to > /usr/src/linux-x.x.x every time I go and build a kernel so that > split-include.c gets the correct header files..
See, again, split-include.c is not needing actual kernel header files. It just needs a C API with roughly POSIX features. The exact version of kernel headers that your C compiler environment uses should not matter a bit.
> 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: their Makefiles are usually written to let you do `make CC=whatever' and have it just work. I have a kernel patch out there (http://peter.cadcamlab.org/linux/) to this effect.
-- Peter Samuelson <sampo.creighton.edu!psamuels>
- 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/
| |