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
[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/

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