LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 02-13-2010, 01:59 AM   #46
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,559

Rep: Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351

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).
 
Old 02-13-2010, 02:54 AM   #47
samac
Senior Member
 
Registered: Mar 2004
Location: Kirkwall, Orkney
Distribution: Linux Mint 20.3 - Cinnamon
Posts: 1,425

Original Poster
Rep: Reputation: 139Reputation: 139
Thanks for the explanation Robbie.

Here is my glibc compile time information.
Quote:
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.

samac
 
Old 02-13-2010, 03:39 AM   #48
grissiom
Member
 
Registered: Apr 2008
Location: China, Beijing
Distribution: Slackware
Posts: 423

Rep: Reputation: 45
Yes, the same to you here. I think the multilib is the reason.
 
Old 02-13-2010, 05:57 AM   #49
GazL
LQ Veteran
 
Registered: May 2008
Posts: 6,873

Rep: Reputation: 4982Reputation: 4982Reputation: 4982Reputation: 4982Reputation: 4982Reputation: 4982Reputation: 4982Reputation: 4982Reputation: 4982Reputation: 4982Reputation: 4982
Quote:
Originally Posted by rworkman View Post
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.
 
Old 02-13-2010, 09:03 AM   #50
jong357
Senior Member
 
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Rep: Reputation: 52
Quote:
Originally Posted by GazL View Post
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.

Last edited by jong357; 02-13-2010 at 09:07 AM.
 
Old 02-13-2010, 10:02 AM   #51
grissiom
Member
 
Registered: Apr 2008
Location: China, Beijing
Distribution: Slackware
Posts: 423

Rep: Reputation: 45
Thanks GazL for speaking loudly what I want to say but didn't. But I will always respect Pat's choice.
 
Old 02-13-2010, 10:19 AM   #52
Petri Kaukasoina
Senior Member
 
Registered: Mar 2007
Posts: 1,716

Rep: Reputation: 1406Reputation: 1406Reputation: 1406Reputation: 1406Reputation: 1406Reputation: 1406Reputation: 1406Reputation: 1406Reputation: 1406Reputation: 1406
Quote:
Originally Posted by jong357 View Post
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
kernel panic after update to -current Intel_ Slackware 14 05-02-2010 11:32 PM
canīt boot updated kernel slackware current jcamez Slackware 19 01-10-2010 08:20 AM
Kernel, GLIBC update, no Alsa! But I can get sound. swinchen Slackware 3 10-28-2004 01:52 AM
kernel-update, a success... BUT... couldn't boot from the updated-kernel Pisces107 Red Hat 7 12-17-2003 02:27 PM
updated kernel from mandrake update? paradoxni Mandriva 1 10-31-2003 02:51 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 10:46 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration