> Huh?
> % ls -ld /usr/include/linux
> drwxr-xr-x 6 root root 18432 Sep 2 22:35
> /usr/include/linux/
>
> > So if we create a separate /usr/src/linux/include/kernel dir, does that
> > imply that we'll have a 2nd link:
>
> What 2nd link? There should be _no_ links from /usr/include to the
> kernel tree. Period. Case closed.
---
> ll -d /usr/include/linux
lrwxrwxrwx 1 root root 26 Dec 25 1999 /usr/include/linux ->
../src/linux/include/linux/
---
I've seen this setup on RH, SuSE and Mandrake systems. I thought
this was somehow normal practice?
> Stuff in /usr/include is private libc copy extracted from some kernel
> version. Which may have _nothing_ to the kernel you are developing for.
> In the situation above they should have
> -I<wherever_the_tree_lives>/include
> in CFLAGS. Always had to. No links, no pain in ass, no interference with
> userland compiles.
>
> IOW, let them fix their Makefiles.
---
Why would Linus want two separate directories -- one for 'kernel-only'
include files and one for kernel files that may be included in user
land? It seems to me, if /usr/include/linux was normally a separate
directory there would be no need for him to mention a desire to create
a separate kernel-only include directory, so my assumption was the
linked behavior was somehow 'normal'.
I think many source packages only use "-I /usr/include" and
make no provision for compiling against kernel header files in
different locations that need to be entered by hand. It is difficult
to create an automatic package regeneration mechanism like RPM if such
details need to be entered for each package.
So what you seem to be saying, if I may rephrase, is that
the idea of automatic package generation for some given kernel is
impractical because users should be expected to edit each package
makefile for their own setup with no expectation from the packages
designers of a standard kernel include location?
I'm not convinced this is a desirable goal.
:-/
-linda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
