Should glibc be updated in current every time there is a kernel update?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.27.7 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.
It can be inferred from this that the answer is no, you do not have to upgrade glibc when the kernel is updated, rather, you ONLY have to update the kernel headers when you update glibc.
Indeed. I think what confuses people is that Pat releases new kernel-header packages with each updated kernel in the patches directory, which is a direct contradiction of that explanation. However, I suspect that these packages have the same contents as the previous one and are just a name change to keep the numbers in sync. But I've never tested this theory by unpacking them and comparing them to each-other, so I might be barking up completely the wrong tree here.
Thank you GazL. You have got the point that I am making. I am not building a custom kernel, I am following the Slackware64-current release. I have read Alien Bob's explanations, and as you say
Quote:
which is a direct contradiction of that explanation
this appears to be the case. I also suspect that they are the same, but I would like to have some sort of definitive answer.
What kernel-headers were used to compile the latest glibc in current?
What kernel-headers are to be used on a running current system?
Why are the headers updated at the same time as a kernel bump if you should not change the kernel-headers?
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810
Rep:
Yes, I too can see your basis for confusion. I must admit it is a little odd. I have compared the versions of kernel headers that come with Slackware64 13. There are two kernel versions supplied being 2.6.29.6 and 2.6.30.5 in /testing. The kernel headers supplied differ with these two (both in number of included files and the actual size of these files). I have not looked to see what the actual differences are, perhaps nothing untoward that would make the versions incompatible. However - obviously there is only the one version of glibc supplied. So which version of the headers was it built against ?
Hmm - now I am confused. I always thought the golden rule was to keep the headers that glibc had been built against but here we appear to have one glibc and two versions of headers ! Hopefully someone more versed with the intricacies of kernels, their headers and glibc can comment on this.
BrZ, there are several headers from the kernel which conflict with headers installed by glibc or other packages like drm. In the case of scsi.h, the one from glibc should be used. Likewise, the headers for drm should be taken from the drm sources and not the ones from the kernel-headers -although now drm is using the headers from the latest kernel -but these may not be the same as what is installed with your kernel-headers package.
As for what's going on with current, it may just be that an entry didn't get written into the ChangeLog or not in the right order -but I wouldn't be sure of that. The trouble is that glibc won't tell you what versiuon of headers were used. Normally, Pat upgrades the headers and then re-compiles glibc against them as is proper, but maybe there is some delay this time for some reason. What I find more perplexing is that the slackware kernel-headers are not sanitized headers -at least as far as I can see. The headers appear to be the complete and raw headers from the kernel sources which is supposed to be a Bad Thing ever since kernel-2.6 was introduced. However, the normal method for creating sanitized headers is also not perfect -I find that some essential headers are missed when using the 'make headers_install' rule. My guess is that Pat avoids the trouble of discovering which headers are missing and correcting the problem, by simply including *all* the headers in the kernel-headers package. There never has been a SlackBuild for the kernel-headers package, so we don't really know how Pat creates them.
As long as you do not upgrade your glibc package, you should not upgrade or remove the kernel-headers package.
So why does Pat keep building new kernel-header packages then? ;-)
I've never understood it. It just promotes misunderstanding and people constantly update their kernel headers because they don't know any better.
Just my 2 cents anyway. When pushing out new source, kernel and module packages, there shouldn't be an accompanying headers package. There's just no need for it what-so-ever....
As is suggested by the documentation we should all be running the version of the kernel headers that glibc was compiled against. Perhaps a Slackware could give a definitive answer to the questions.
Quote:
What kernel-headers were used to compile the latest glibc in current?
What kernel-headers are to be used on a running current system?
This would then put all our collective minds at ease. Perhaps it would also be good to remove the uncertainty by only updating the kernel headers when glibc is compiled against different set of headers.
Unless you turn around and re-compile glibc which he usually does. But, that should imply re-compiling everything in the distro -which we know never happens -hence those pesky little errors that crop up much later or anytime a user thinks they can re-compile anything/everything in the distro at any point in time. Luckily, the 64bit branch exposes many problems which would otherwise go undetected for a longer time.
So should Slackware get an overhaul, so it is freshly compiled, just as Slackware64 has been. In fact should Slackware be completely re-compiled for each new tool-chain/release? This should actually improve Slackware and make it even better than it already is.
Unless you turn around and re-compile glibc which he usually does.
In current yes, but Pat also seems to provide new header packages in the stable/patches directory when the kernel is updated for security reasons and I think it's this that has everyone confused.
Am I the only one that thinks maybe slackware is TOO STABLE? I mean if we had some good show stopping bugs would this thread have made it to two pages?
Am I the only one that thinks maybe slackware is TOO STABLE? I mean if we had some good show stopping bugs would this thread have made it to two pages?
If there's anything that signifies a slackware user then it's that they like to understand how their system works. Not understanding something as fundamental and important as what goes into the system headers is bound to be an itch that wants scratching.
Someone posted the other day that notify-send (libnotify) wasn't working, and didn't get a whole lot of help. That was show-stopping for them and resulted in them returning to Ubuntu because of it. There was also that unexplained memmove() pointer corruption/segfault in ash I was investigating last week, though as no one uses ash interactively, I can understand the lack of interest in that one. Slackware has its bugs just like any other distro. It's just that most of us never encounter them.
Try re-compiling each and every package at any point in time and you are liable to trun up lots of compile-time problems. runtime is another thing. GazL, did you ever come up with a definitive fix for ash?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.