[SOLVED] Must original kernel headers 2.6.37 be reinstall before recompile of current?
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Must original kernel headers 2.6.37 be reinstall before recompile of current?
Want to recompile kernel 3.2.21 and i have been running:
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/
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
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.
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
Last edited by NightSky; 07-09-2012 at 07:40 PM.
Reason: Why do i need to download source if its on the box already?
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!
Distribution: Slint64-14.2rc on Lenovo Thinkpad W520
Originally Posted by NightSky
I understand know the kernel headers are required for modules(drivers) built against that particular header.
No really. Re read what gnashley wrote:
When you compile a kernel, the compile process does not look anywhere else for anything outside the kernel sources
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.
Last edited by Didier Spaier; 07-13-2012 at 01:18 AM.
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.