[PlanetCCRMA] Kernels and Planet

[James van Zeeland]

scripts/split-include include/linux/autoconf.h include/config
gcc -D__KERNEL__ -I/usr/src/linux-2.4.21-1.ll.acpi/include -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
-fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686   
-DKBUILD_BASENAME=main -c -o init/main.o init/main.c
In file included from init/main.c:40:
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:34:23: acpi/acpi.h: 
No such file or directory
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:35:27: 
acpi/acpi_bus.h: No such file or directory
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:36:31: 
acpi/acpi_drivers.h: No such file or directory
In file included from init/main.c:40:
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:82: field `header' 
has incomplete type
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:89: field `header' 
has incomplete type
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:96: field `header' 
has incomplete type
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:105: field `header' 
has incomplete type
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:227: field `header' 
has incomplete type
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:241: field `header' 
has incomplete type
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:295: field `header' 
has incomplete type
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:303: field `header' 
has incomplete type
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:312: field `header' 
has incomplete type
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:313: field 
`ec_control' has incomplete type
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:314: field 
`ec_data' has incomplete type
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:377: field `id' has 
incomplete type
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:380: parse error 
before "acpi_handle"
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:380: warning: no 
semicolon at end of struct or union
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:380: warning: no 
semicolon at end of struct or union
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:381: warning: 
built-in function `index' declared as non-function
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:382: parse error 
before '}' token
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:382: warning: type 
defaults to `int' in declaration of `link'
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:382: warning: data 
definition has no type or storage class
/usr/src/linux-2.4.21-1.ll.acpi/include/linux/acpi.h:384: parse error 
before '}' token
make: *** [init/main.o] Error 1
[root at Orbit linux-2.4.21-1.ll.acpi]#

bummer.

Can anyone tell me what I need to fix this? acpi code, presumably, but 
since it returned much the same response for the previous 2.4.20 planet 
kernel, I wonder why the acpi code is left out or whatever...is the code 
some sort of planet secret or something? :-) Unfortunately it means I 
won't use the planet kernel, and looks like I'll just use ck instead.

This is much the same as the response from attepting to compile an RH9 
kernel from source, if I recall. just replace acpi with devfs. 
So....since neither redhat nor the planet kernels seem to be fixing 
these between point releases, what should I do to make them compile? I 
can navigate C code, but am not any kind of adept at programming it. For 
now I'll presume it's one of those "we're teaching you and you'll thank 
us for it" type gotchas. if you know what I mean :-)

Obviously they can be compiled, or there wouldn't be a binary release! 
But then the binary release is 2.4.21-1.ll.caps or something, so what's 
the difference between the binary and source, and why is there no 
kernel-source to match? Certainly when using the previous 2.4.20 planet 
kernel, for which the binary/source versions matched exactly, according 
to the docs, the source would allow me to compile modules, but they 
would be totally unuseable, and invariably have unresolved symbols.

In a nutshell, this is why I'm using RH8 kernels for servers and ck for 
workstations, as I've found I have fewest issues if I compile 
everything; kernel, standard and extra modules from source...

Not meaning to whinge or anything...apart from the kernel, planet would 
have to be the best solution for audio/media I've yet seen, and I'm sure 
the kernel would be great....if I could compile it...I guess a lot of
end users don't need to but I do.

J