LinuxQuestions.org
Visit Jeremy's Blog.
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 05-31-2009, 03:29 PM   #1
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 546Reputation: 546Reputation: 546Reputation: 546Reputation: 546Reputation: 546
Which Packages Depend Upon Kernel Headers, glibc, gcc, etc.?


With each new Slackware release, there is a more recent kernel, development tools, etc. Yet not all packages are recompiled. Actually many are not. Many packages with updated versions are recompiled, but are not dependent upon kernel changes, etc.

Which packages are significantly dependent upon kernel sources/headers, updated development tools, etc.?

I'm browsing the changelog and haven't got a good understanding about how that works.

Thanks.
 
Old 05-31-2009, 07:07 PM   #2
piete
Member
 
Registered: Apr 2005
Location: Havant, Hampshire, UK
Distribution: Slamd64, Slackware, PS2Linux
Posts: 465

Rep: Reputation: 44
I've not looked into this specifically, but in general maybe this'll help.

binutils/gcc are really nothing more than programs who are very picky about their glibc versioning, so as far as dependencies go: they're pretty stand alone.

Aside from that, there are three separate parts:

* Kernel. Any time you change the kernel, you need to recompile drivers/modules, because these are linked against *your* kernel sources. Just like at home with a custom kernel and, say, the nVidia drivers. This is not the same as ...
* Kernel headers. These are (or should be) specifically sanitized kernel headers that were used to build ...
* glibc-solibs (shared objects from a glibc build). Which represents a portion of pretty much every the dynamically linked binary you've got. Anything with a printf in it, for example, will depend on glibc.

The thing is, a dynamically linked library is going to run off and call the piece of code that it's linked against if it can find it. My knowledge of how exactly it does that gets a bit hazy at this point and I doubt you're really that interested anyway, but the term you want is ABI - application binary interface. If the ABI changes (say printf gets deprecated in favour of print_f) then the dynamically linked part of your binary is going to get a little lost and probably your program won't work anymore.

So long as the ABI remains static (or backward compatible), there's no sense in a recompile because your program already knows where to find it's extra bit of code. If someone has changed the contents of that function (say printf is now made 100% more efficient!) ... it actually makes buggerall difference since printf is still a black-box as far as your program is concerned.

So you can see there is a disconnect between the currently running kernel and the kernel headers required to compile glibc.

The long story short is, very little truly depends on anything else to the extent that it calls for a complete rebuild

My apologies for the rambling, I hope this is of some use and you've got some more keywords to go rummaging through!

- Piete.
 
Old 06-05-2009, 11:40 AM   #3
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Original Poster
Rep: Reputation: 546Reputation: 546Reputation: 546Reputation: 546Reputation: 546Reputation: 546
Thanks for the reply.

I don't pretend to know the nuances with package relationships to core packages. I have noticed I can update a Slackware release to the next version and the new release seems to function fine with the kernel from the previous release --- at least my recompiled version.

I realize the traditional philosophy is don't mix pacakges from different releases, especially Current. Yet there seems to be breathing room if a person updates a package with some caution and intelligence.

Another alternative is to use the existing build scripts to update packages.

I posted this question because the 2.6.29.4 kernel locks my NIC with a soft reboot, which also locks my router port, and then requires toggling everything off/on to restore. I might want to update to Current when officially released, but not the kernel. Or, use the 2.6.28.10 kernel instead of 2.6.29.4. I've encountered nuisances like this before, but this time no solution seems forthcoming. I haven't tried any of the 2.6.30.x sources.

Quote:
Kernel. Any time you change the kernel, you need to recompile drivers/modules, because these are linked against *your* kernel sources. Just like at home with a custom kernel and, say, the nVidia drivers.
Yes, that much I knew. I routinely recompile my own kernel. Related, I always recompile the nvidia drivers, VirtualBox, etc., when I recompile the kernel. I think the primary reason is not so much that I've made any dramatic changes to the kernel, but the internal kernel name is different and the modules need to match.

Quote:
glibc-solibs (shared objects from a glibc build). Which represents a portion of pretty much every the dynamically linked binary you've got.
If I understand correctly, as long as the kernel version remains the same, the headers remain static and unchanged, and therefore glibc-solibs does not need to be rebuilt. However, I can update and recompile the kernel but not update the headers. In that case, I need not rebuild glibc-solibs. Only when I update the headers do I need to rebuild glibc-solibs. Do I understand correctly?
 
Old 06-05-2009, 02:05 PM   #4
piete
Member
 
Registered: Apr 2005
Location: Havant, Hampshire, UK
Distribution: Slamd64, Slackware, PS2Linux
Posts: 465

Rep: Reputation: 44
Disclaimer: I don't intend to patronize, so please accept my apologies if you feel that way. I'm talking at length to give others who may have an interest some more information as well as picking up some new information myself

Quote:
as long as the kernel version remains the same, the headers remain static and unchanged
The running kernel version does not have to match 1:1 the kernel headers that glibc is built against.

From glibc.SlackBuild (which incidentally builds glibc-profile, glibc, glibc-solibs, glib-i18n and glibc-zoneinfo):

-current
Code:
../configure \
...
  --enable-kernel=2.6.18 \
  --with-headers=/usr/include \
...

12.2
Code:
KERNEL_HEADERS=2.6.27.7
 ...
  --with-headers=/usr/src/linux-${KERNEL_HEADERS}/include \
-current is built against /usr/include (--with-headers), while releases seem to be built against the kernel version that's shipped. In both cases, however, there is a minimum kernel ABI given (--enable-kernel=2.6.18).

Quote:
Only when I update the headers do I need to rebuild glibc-solibs. Do I understand correctly?
Yes. If you change your kernel headers, you should rebuild glibc. The only reason for a header change is if you have a program that requires something from glibc that requires something from a kernel that you do not currently have.

That is to say, your userspace program has a dependency on glibc > X because of some call that talks to a kernel mechanism that only appeared in kernel > Y.

If you're having driver/module problems, then up- and down-grading your kernel is perfectly safe and doesn't require you to rebuild the rest of the system under the proviso you don't step out of bounds of what your system requires. In this case downgrading past 2.6.18 would likely result in a lot of error messages like "FATAL: kernel too old." and upgrading too far may cause breakage due to ABI changes in the kernel. Too far would have to be a long way, I suspect.

What's usually a good idea is to leave your kernel headers installed (the kernel source in this case) and compile and install another kernel version along side it.

I'm currently running 2.6.18.8 (over 2.6.26.something) because someone broke my LiveDrive. Downgrading much further would probably be bad

Hope that helps,
- Piete
 
  


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
determine what packages depend on a given rpm bradvan Linux - Software 7 05-07-2009 09:22 AM
Automatic removal of kernel headers package when kernel packages are removed bgoodr Debian 3 12-30-2008 08:14 PM
Glibc Unable to Find Kernel Headers Kenji Miyamoto Linux From Scratch 6 12-30-2008 04:03 PM
kernel headers and glibc BCarey Slackware 9 09-17-2006 09:56 PM
the first gcc in CLFS1 do not need the Glibc headers of target? augustus Linux From Scratch 2 09-16-2006 08:36 AM

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

All times are GMT -5. The time now is 09:58 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