LinuxQuestions.org - Errors Compiling Kernel 2.6 on Slackware 10.2

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Errors Compiling Kernel 2.6 on Slackware 10.2 - Old kernel headers required? (https://www.linuxquestions.org/questions/slackware-14/errors-compiling-kernel-2-6-on-slackware-10-2-old-kernel-headers-required-421049/)

Errors Compiling Kernel 2.6 on Slackware 10.2 - Old kernel headers required?

When compiling kernel 2.6.15 in a minimal slackware 10.2 install, the following error occurs.

I've verified all prerequisites for compilation. I've experiemented with the slackware 10.2 CD and noticed that, if I install the kernel-headers package (which says it's for kernel 2.4.31, the currently-installed kernel), the 2.6 kernel compiles without any errors whatsoever.

Am I wrong in saying that a 2.6 kernel should NOT need a previous kernel's headers?

-Dave

-----------

CHK include/linux/version.h
HOSTCC scripts/basic/fixdep
In file included from /usr/include/bits/posix1_lim.h:153,
from /usr/include/limits.h:144,
from /usr/lib/gcc/i486-slackware-linux/3.4.4/include/limits.h:122,
from /usr/lib/gcc/i486-slackware-linux/3.4.4/include/syslimits.h:7,
from /usr/lib/gcc/i486-slackware-linux/3.4.4/include/limits.h:11,
from scripts/basic/fixdep.c:113:
/usr/include/bits/local_lim.h:36:26: linux/limits.h: No such file or directory
In file included from /usr/include/sys/socket.h:35,
from /usr/include/netinet/in.h:24,
from /usr/include/arpa/inet.h:23,
from scripts/basic/fixdep.c:115:
/usr/include/bits/socket.h:304:24: asm/socket.h: No such file or directory
scripts/basic/fixdep.c: In function `use_config':
scripts/basic/fixdep.c:201: error: `PATH_MAX' undeclared (first use in this function)
scripts/basic/fixdep.c:201: error: (Each undeclared identifier is reported only once
scripts/basic/fixdep.c:201: error: for each function it appears in.)
scripts/basic/fixdep.c:201: warning: unused variable `s'
scripts/basic/fixdep.c: In function `parse_dep_file':
scripts/basic/fixdep.c:297: error: `PATH_MAX' undeclared (first use in this function)
scripts/basic/fixdep.c:297: warning: unused variable `s'
make[2]: *** [scripts/basic/fixdep] Error 1
make[1]: *** [scripts_basic] Error 2
make: *** [include/linux/autoconf.h] Error 2

Installing SW10.2 test26.s kernel require 2.6.13 kernel modules but 2.4.3x kernel-headers. So it makes sense to keep same kernel-headers package when compiling newer 2.6x kernel. I would check SW current changelogs for any changes regarding kernel-headers because current uses 2.6.14x and 2.6.15x testing kernels.

Okay, that makes sense because it did compile without errors, but i'm a little confused - why would compiling a 2.6 kernel require 2.4 kernel headers?

kernel-headers and new 2.6 kernel

Pat explains it in changelog for SW10.2 with regards to testing26.s install kernel(2.6.13). I just obey eventhough a part of my brain wants to keep headers and kernel versions the same.

Quote:

This package of 2.6.x based /usr/include/linux and /usr/include/asm headers
is being provided by request for some people who need it in order to compile
ASDL modem drivers for 2.6.x. As a general rule, installing kernel headers
that are newer than the kernel glibc was compiled with *may* cause problems,
so unless you need these for a particular reason it's best to stick with the
2.4.x kernel-headers package for now.

Note -- if you compile with NPTL then you might want to use these headers,
and glibc's NPTL was compiled using 2.6 headers, so all should be well.
In that case, specify using NPTL libs and headers with these compile
options:

-I/usr/include/nptl -L/usr/lib/nptl

Good luck!

-P.

ftp://ftp.oregonstate.edu/pub/slackw...eaders.WARNING

Okay - thanks. One more question - why would a full kernel source actually need any kernel headers other than what comes in from kernel.org?

Quote:

Originally Posted by Dave S.

Okay - thanks. One more question - why would a full kernel source actually need any kernel headers other than what comes in from kernel.org?

because the version of the headers from kernel.org might be different than the version of the headers your glibc was compiled against...

allow me to quote Linus Torvalds:

Quote:

The fact is, that the header files should match the library you link
against, not the kernel you run on.

Think about it a bit.. Imagine that the kernel introduces a new "struct
X", and maintains binary backwards compatibility by having an old system
call in the old place that gets passed a pointer to "struct old_X".
It's all compatible, because binaries compiled for the old kernel will
still continue to run - they'll use the same old interfaces they are
still used to, and they obviously do not know about the new ones.

Now, if you start mixing a new kernel header file with an old binary
"glibc", you get into trouble. The new kernel header file will use the
_new_ "struct X", because it will assume that anybody compiling against
it is after the new-and-improved interfaces that the new kernel
provides.

But then you link that program (with the new "struct X") to the binary
library object archives that were compiled with the old header files,
that use the old "struct old_X" (which _used_ to be X), and that use the
old system call entry-points that have the compatibility stuff to take
"struct old_X".

Boom! Do you see the disconnect?

http://www.uwsg.iu.edu/hypermail/lin...07.3/0587.html

just my :twocents:...

Quote:

because the version of the headers from kernel.org might be different than the version of the headers your glibc was compiled against...

Agree. Try to upgrade your GCC (3.4.5) and glibc (2.3.6). It worked for me. I just upgraded my kernel to 2.6.15.5 last night :D

I was having the same problem and now I know what I need...2.4 header