The kernel does not use glibc; the kernel does not use *any* external library; gcc is completely irrelevant.

Installing the Slackware -current kernel onto 14.1 works absolutely fine. I'm typing this from exactly such a system right now. Everything else is 14.1, so it has 14.1's glibc, so don't upgrade the kernel-headers package. Just upgrade kernel-generic, kernel-modules and kernel-source. I don't think kernel-firmware is a big deal whether you upgrade or not.

Does that clarify it for you?

1 members found this post helpful.

I been compiling the kernel a long time many of us have. I want you to read what you wrote. ok now go install the 4.16 kernel on 14.1. and then go compile the any extra drivers you need. You will learn fast about the kernel you are running and the kernel you are teying to compile.
Install it now go install NVIDA or an ati module. if you build that kernel with that gcc and that glibc then you better stick with it all the way through. Learn from Pat and watch how he builds his distro. http://docs.slackware.com/howtos:sla...kernelbuilding

There is a difference between the running kernel and the kernel source and the headers and what glibc they where built against.
so you installed the kernel. how is it going to run your system with out building and installing the /lib/modules.
Oh I have a slackware 14.1 and I installed the kernel 4.16 from current have no idea why my system does not run.
so now you install the kernel modules ok it boots. now you try to compile your video drivers hello.
Learn what the Glibc and the Kernel headers are. you need to recompile the kernel from souce. understand /usr/include/linux how it was created.
The thought you advise some one to download and install a kernel just the kernel. that was built on a complete different system is just bad advice. There is a reason why there is a kernel package a kernel-modules package a kernels header package and a kernel firmware package. You ever wonder why they were built on the same system. You ever wander about uninstalling the kernel headers and linking the source kernel headers to /usr/include/linux. You do that when you want to start somthing new. The gcc is not as important as glibc. But when you compile software it is linked to /usr/include/linux and guess what they better match or stuff does not build.

Please don't patronise me, sir.

Who do you think has updated the nvidia legacy-96 and legacy-173 SlackBuilds for -current?

You'd be well advised to stop digging that hole you're in.

1 members found this post helpful.

you told another user to use built packages from another system. You Sir gave bad advice. Have him grab the source and build it the slackware way.

You are going to build and use a new kernel. You may wonder what you need to do with the Slackware kernel-headers package.
The answer is: do not remove this package!

There are two places where you will find kernel headers; one place is inside the kernel source directory (in our case, the /usr/src/linux-2.6.37.6 directory) and the other place is /usr/include/linux. The kernel-headers package usually contains the headers taken from the source of the default Slackware kernel. These particular headers are used when the glibc package is built. The fact that the kernel-headers package installs these files to /usr/include/linux makes them independent of the header files you find in the kernel source directory.

As long as you do not upgrade your glibc package, you should not upgrade or remove the kernel-headers package.

How do the kernel-headers and glibc packages relate?
At some point in time you will want to upgrade (recompile!) parts of your system's software. If that software links against glibc (as most core software does), it's successful compilation relies on the presence of the correct kernel headers in /usr/include/linux. It does not matter that you are propably running an entirely different kernel than Slackware's default kernel. The kernel-headers package reflects the state of the system at the time glibc was built. If you delete the kernel-headers package, your running system will in no way be affected, but you will not be able to (re-)compile most software.

Do the kernel sources still serve a purpose after you have built your new kernel?
In the previous bullet point I told you that the compilation of system software uses the headers located in /usr/include/linux. Likewise, the kernel source tree is required any time you want to compile a 3rd-party kernel module (madwifi, linux-uvc, ndiswrapper, the list is endless). You are not limited to compiling a driver for your running kernel. You can build drivers for any kernel as long as its modules tree (below /lib/modules) and sources are present.
Let's say you are going to build a module for a kernel whose version you have specified in an environment variable $KVER. For instance, by running

Understand the glibc and slackware's glibc-package

[citation needed]

1 members found this post helpful.

The first rule of Kernel Developer Club is; "DON'T BREAK USERSPACE!". Linus and friends go to a great deal of trouble to keep new kernels backward compatible with a userspace built against old headers. Because of this there should be no problem borrowing a kernel and its associated modules package from -current for use in 14.1.

Of course, in real life it's never that simple. On rare occasions one might find that some low level stuff like ethtool, dhcp, iptables, etc. might break and need updating for use with newer kernels, but usually this is because they need to be updated for the new kernel and not that the kernel was borrowed. You'd hit the same issues if you downloaded and built a newer kernel on your 14.1 system.

Correctly written out of tree kernel modules should find headers from the /lib/modules/$(uname -r)/build symlink and not /usr/include/linux, which is why you can build/install the nvidia drivers for a non-running kernel with a command like ./NVIDIA*.run -k $KERNEL_VERSION (so long as the kernel, its source and its modules directory are already in place). Any out-of-tree kernel module developers that are still using /usr/include/linux in their builds need to receive a good whack from a clue-stick.

Of course, errors can slip through, and there may be the occasional edge-case, but in principle, borrowing a kernel and modules package from current should work. Having said that, its probably not wise for a newbie to do, as they will be ill equipped to deal with any potential fall-out.

1 members found this post helpful.

@Drakeo, you know, there's a reason I always tell users to use installpkg instead of upgradepkg when I tell them to install a newer kernel. Installing the kernel-huge, kernel-generic, kernel-modules and kernel-firmware will not replace anything of the previous kernel. You included it in your text:

So, upgrading the kernel won't replace the files in /usr/include/linux.

Plus, when you upgrade packages, they don't base their builds on the headers in /usr/include/linux, they base it on the header files in the kernel's source directory (another thing you included in your text). As Gazl pointed out, and as 55020 has no doubt experienced (and probably what he was alluding to), this is why you're able to compile kernel modules on kernels that don't match your "kernel" headers. In actuality, these should probably be glibc-headers, since they don't have anything to do with the running kernel, but only the kernel they were compiled on.

Also, even if a user were to upgrade their kernel-headers package (which is located under the d/ series, so not easily found if they're just looking in a/ -- the actual kernel is located in a/ and the source is located in k/), the kernel developers do their best to maintain backwards compatibility (as GazL mentioned). And I've been able to know this firsthand. When I was young and dumb in my linux days, I remember when Slackware released a 2.6 kernel in the testing/ folder (on Slackware 11.0). I thought, "Ooo, shiny!" and installed it, and I disregarded the warning about the kernel-headers package, because I figured that 2.6 headers must be better than 2.4 headers. I ran that system for 9 months (until Slackware 12.0 came out), compiling who knows how much software and modules (my wifi required modules from Intel that didn't exist in the kernel at that time), and I didn't run into issues. I certainly wouldn't recommend others to do this because of the possibility of failing compiles, but, like I said, I didn't have any issues.

Maybe I should be a bit more careful with my verbiage and specifically mention that users should not install the kernel-headers package from -current, but installing the actual kernel from current/ won't affect your 14.1 system as long as you use installpkg instead of upgradepkg. Then you just edit lilo.conf, run lilo, then reboot. If a user wants to compile the kernel on their machine, they're more than welcome, but the kernel doesn't rely on your system's dependencies, so it can be installed without worry.

Now running 4.1.9 LTS with zero issues so far. GT-730 + nvidia driver, Phenom(tm) II X4 B55