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.
Fair point. However, for us, it *is* an accurate indication of the kernel-headers that were present when glibc was compiled. When the glibc package is created, the headers will match the running kernel (or will at least be in that same series ala the earlier statements I made).
samac@quad:~$ /lib64/libc.so.6
GNU C Library stable release version 2.11.1, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.2.
Compiled on a Linux >>2.6.29.6<< system on 2010-01-02.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
So According to your explanation, I should be running the kernel headers for something in the 2.6.29.x series, which is fine, however I am following current and the kernel series is 2.6.32.x.
It has been said on this thread, quoted from reliable sources, that you should not update your kernel-headers, you have said that the kernel headers within a stable series are compatible. Your kernel-headers used when glibc was compiled and mine differ, perhaps the difference is that I have the following packages installed.
Quote:
samac@quad:~$ ls /var/log/packages/glibc-*
/var/log/packages/glibc-2.11.1_multilib-x86_64-1alien
/var/log/packages/glibc-i18n-2.11.1_multilib-x86_64-1alien
/var/log/packages/glibc-profile-2.11.1_multilib-x86_64-1alien
/var/log/packages/glibc-solibs-2.11.1_multilib-x86_64-1alien
/var/log/packages/glibc-zoneinfo-2.11.1_multilib-noarch-1alien
Perhaps this therefore is a discussion that I should have with AlienBob.
I guess because it's trivial enough to do it by hand.
Yep, I can appreciate that. However, what a kernel-headers.SlackBuild would provide is documentation of the process for all to see. You already mentioned in a previous post some skulduggery necessary to fix some scsi header conflict. What this entails would be visible if a SlackBuild script was used to do it.
Having said that, Slackware is a binary distribution, and though Pat includes the build tree, it's fairly clear that it's provided as is and not considered part of the 'product' in any way, which is fair enough as there's no onus on him to provide it. That doesn't change the fact that it'd be nice to have though.
Yep, I can appreciate that. However, what a kernel-headers.SlackBuild would provide is documentation of the process for all to see. You already mentioned in a previous post some skulduggery necessary to fix some scsi header conflict. What this entails would be visible if a SlackBuild script was used to do it.
Having said that, Slackware is a binary distribution, and though Pat includes the build tree, it's fairly clear that it's provided as is and not considered part of the 'product' in any way, which is fair enough as there's no onus on him to provide it. That doesn't change the fact that it'd be nice to have though.
I agree. This is opensource and all build procedures should be clearly documented, if not for the only reason of quelling inqueries such as those found in this thread. When you start hiding things, people will naturally inquire..... That being the point, I'm also curious to know what you've done about the drm headers and scsi.h...... Sure, I could find out with diff and some source code and binary packages but it would be alot nicer if it were documented as is proper for a an opensource linux distribution...
When I querry libc.so.6 on my DIY build, it spits out "Compiled on a Linux >>2.6.29.6<< system" because I bootstrapped on a Slackware64 13.0 host. So, naturally, that was the running kernel at the time. The kernel headers I compiled glibc against are however 2.6.31.12...
I know you've already covered that issue Robby (and was corrected and acknowledged said correction), but perhaps it's fair to say that if your running Slackware64 13.0's stock glibc then you need to be running Slackware 13.0's stock kernel headers, both of which can be easily found out.
I still think the incessant kernel-headers package releases should stop. When there is only one version of kernel-headers available, threads like this become moot.
perhaps it's fair to say that if your running Slackware64 13.0's stock glibc then you need to be running Slackware 13.0's stock kernel headers
I would say that it does not matter. If you run on a newer kernel, usually you can as well use kernel headers from that. It would be interesting to hear about a real life example of any recent problems.
The kernel headers define available system calls, and structures and constants used with them. New stuff is added to kernel but nowadays very strong arguments are needed for removal of old stuff or otherwise causing backwards incompatibility. Even when that happens, it's not something glibc or glibc users see. At least there would be a very long transitional period. (Userspace tools like iptables which are close to kernel or hw drivers can be different, there have been changes which have affected compiling them. But they #include kernel headers directly: it's not about kernel headers being of different version than those glibc was compiled against.)
If your newer kernel headers define some interesting new system calls that the latest glibc could use, glibc cannot use them if you don't recompile glibc, and you may very well need newer glibc source, too. But the new definitions do not do any harm either.
Last edited by Petri Kaukasoina; 02-13-2010 at 10:44 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.