Want to recompile kernel 3.2.21 and i have been running:
slackpkg update
slackpkg upgrade-all
to keep slackware64 current. I never blacklisted the kernel
let slackpkg upgrade it.
The question is to recompile slackware64 current with kernel 3.2.21
do I have to reinstall the original kernel headers?
Only contents in /usr/src/
linux-3.2.21
linux (link)
Or can i just use the linux-3.2.21 kernel source to recompile?

Also when lilo puts out the LBA32 warning after update how do you fix that. I have an entry for winxp that is 32 os on lilo. thank you

You have to use the packaged headers that come paired with the copy of glibc that Slackware includes. Rebuilding a kernel with new headers will not work unless you rebuild glibc.

1 members found this post helpful.

Thank you ReaperX7, Just to be clear the glibc are paired with the current kernel headers 3.2.21 Correct? So I don't need to reinstall the original distro headers?

Not exactly... what you want to do is grab the kernel-headers-3.2.12 version package and install them back onto the system.

Installing the headers from a compiled kernel, even if the same version, may not work correctly.

For safe measure... stick to whatever kernel headers are released with glibc from Patrick.

1 members found this post helpful.

If your Slackware64-current is up to date the kernel headers should be there and should not be removed nor upgraded

To know more, read Building a Linux Kernel from source from Eric Hameleers.

1 members found this post helpful.

No, actually the kernel-headers package is irrelevant to the kernel sources. When you compile a kernel, the compile process does not look anywhere else for anything outside the kernel sources -no stdlibs, no headers no nothing. It's unfortunate that the kernel-headers are not named otherwise as it leads people to believe there is a relationsip between them and the running kernel (or one you want to compile. Do not upgrade your kernel-headers package unless you are also upgrading glibc.

1 members found this post helpful.

Thanks, I have Eric's tutorial printed out. Reading tons (kernel docs & Readme) just confused over not removing 'Kernel Headers'. Knew I have the currently installed kernel headers per /var/log/packages. I want to Recompile the current kernel 3.2.22 not upgrade, according to: http://blog.tpa.me.uk/slackware-kernel-compile-guide/ - but i want to use the old.conf as base to customize for machine's architecture and usage. Also want to keep current kernel setup as an option in Lilo. I'm not ready to compile a whole new kernel nor do I need to yet Here is a detailed illustration of the kernel build process: http://www.bitbenderforums.com/forum...&postid=296303

The kernel headers package really could be named more along the lines of "kernel-glibc-headers" to avoid confusion and show a greater tie-in to glibc.

You know, I've been looking for a straight answer to this question for, well, nearly TWO decades, and here it is in the Slackbook--something I thought I would never need. *smacks forehead* I've heard similar answers before but never WHY until now! It explains so much about losing stability when compiling my own kernel and similar issues. Thank you again EVERYONE who replied on this thread!

I understand know the kernel headers are required for modules(drivers) built against that particular header.

No really. Re read what gnashley wrote:
If you look at some of the files installed by the kernel-headers package (you can list it with "cat /var/log/packages/kernel-headers*") you will see that they are made mainly of constants definitions. This way, application programs which "include" some of these files don't have to define the same constants again, which save time for the programmer and allow to shorten the source code.

This is why kernel-headers' package description states "You'll need these to compile most system software for Linux."

But other packages include header files as well, especially glibc.

Glibc and kernel-headers' header files complement each other and should stay consistent, that's why you shouldn't remove nor upgrade any of those -- unless you don't intend to compile any program, as in this case both packages are useless

This is a very rough explanation, you will find a more detailed and accurate one under the title Slackware "kernel-headers package" in already mentioned Alien Bobs's wiki page.

1 members found this post helpful.

Got it. I won't be removing kernel headers, trust me. I 'm just going to wait for the next stable version of slackware and recompile my kernel right after the upgrade... so I can go ahead and compile programs and apps for this box. Going to reinstall last stable version on an older PIII box and customize that kernel to get comfortable. Appreciate your time & instruction the original question is well answered.

Let me flesh that out just a little. When glibc is compiled, you must 'point' the sources at headers which are part of the kernel sources. This means that you are defining glibc's 'interface' to the kernel. These particular headers from the kernel sources will comprise the 'kernel-headers' package. Indeed, some distros call them the 'libc-headers' -not 'glibc-headers' because they might be from other C library like uclibc.

Any later *software* which you compile may use functions from these headers -but most of the includes needed for compiling *software* come from the development headers in the glibc or any other library needed(GTK, openssl, etc). In order for all the software to work correctly and consistently -according to the same defined interface (the exact headers you used to compile glibc against), the software should also be compiled using the exact same headers. This is why the kernel-headers should only be upgraded along with glibc and not when the kernel is upgraded.

As I said, the kernel sources contain everything needed for compiling that version -you don't need the kernel-headers package for compiling a kernel.

Then, as opposed to *software* mentioned above, if you need to compile an external *kernel module*, then you need to point that build at the sources of the kernel *which you are running* (or the one you intend to use the module with. On a pristine system that would mean pointig the build at the sources included in the kernel-source package. But, if you are building a module for an *updated* kernel, then you need to point the (external) module sources at the sources for the *updated version* of the kernel (and those sources must be pre-configured with the same configs as the running (or planned) kernel.

Within some rare limits, you can *run* any version of the kernel without any regard for the version of the kernel which supplied the libc/kernel-headers for the build of the glibc library. Binary compatibility between programs and libraries is all about matching glibc and any other libraries linked to. The kernel version is critical to *hardware* compatibility. You are unlikely to 'break' a program or library by changing the kernel version.

There is a separate point about compiling glibc, where you define the oldest version of the kernel which can be run with your glibc. For instance, you compile glibc against the headers from the linux-2.6.31 kernel, but you can tell glibc to provide compatibility with kernels as old as 2.6.26. Then, if you try to boot that system running with a kernel-2.6.24, glibc will throw an error: 'Kernel too old' and you will not be able to fully boot the system. The upshot is that all three kernel-version references may be different from the others.

1 members found this post helpful.

Superbly instructional, thank you all; You are Gentle Persons & Scholars Loving every bit.