1i5t5.duncan at cox
Feb 15, 2010, 1:45 AM
Post #3 of 5
Nikos Chantziaras posted on Mon, 15 Feb 2010 09:05:58 +0200 as excerpted:
> On 02/15/2010 06:45 AM, Frank Peters wrote:
>> Doing my daily emerge update, I noticed that a new release of the
>> linux-headers, version 2.6.32, was available. After installing this
>> new version, there appeared a message advising that glibc be re-emerged
>> to take advantage of any new features that might be available in the
>> latest kernel headers.
>> My question is: why are not glibc and the linux-headers linked in a
>> dependency relationship? If re-compiling glibc after emerging a new
>> version of linux-headers could be so important, why not just create an
>> ebuild that will automatically do this via dependencies rather than
>> provide a message that a lot of users may miss?
> There's no way to force a rebuild of something through dependencies.
> Only a revision or version bump can do this.
Additionally, the kernel/userspace boundary, unlike internal kernel
interfaces, is kept relatively stable, and unlike dependencies handled by
revdep-rebuild, glibc should continue functioning just fine as built
against the older kernel.
However, as that post-merge message from the linux-headers ebuild
suggests, remerging glibc (as hinted, the biggest user of these headers)
/does/ allow it to take advantage of new, generally more efficient
interfaces in the new kernel.
In theory that means you shouldn't try to run kernels older than the linux-
headers version you compiled glibc against, but at least for /reasonable/
levels of out-of-sync, I've never read of any problem with it. Perhaps
glibc compiles both old and new interface versions, when there's a change,
and keeps the old ones around for awhile, just in case users do downgrade
kernels below the version they compiled linux-headers against.
>> When glibc is emerged, I assume that only the headers from the linux-
>> headers package are used and not the headers contained in the kernel
>> source tree at /usr/src/linux. Is this correct?
> Depends on the user. External kernel modules always use the headers
> from /usr/src/linux. User-space programs use the header from the
> linux-headers package.
>> Also, what programs, when emerged, would directly use any kernel
>> headers? I assume only programs that need to access hardware directly
>> through kernel functions would need to use these headers. Of course
>> glibc calls the kernel directly, but the only other programs that would
>> need to do so would deal with video or sound or something similar. Is
>> this correct?
> As explained above, user-space uses linux-headers. /usr/src/linux is
> used for building kernel modules. To give examples,
> x11-drivers/ati-drivers and app-emulation/vmware-modules use
> /usr/src/linux (kernel sources package), while media-libs/alsa-lib and
> sys-libs/glibc would use /usr/include/linux (linux-headers package).
IOW, out-of-tree kernel drivers use the kernel's own headers, and glibc as
the major userspace user, plus misc other minor users (alsalibs in the
example), use the separate linux-headers package headers, as placed in
But it's well known that out-of-tree kernel drivers require a kernel to
build against, so that shouldn't be a surprise, and glibc really is the
most important (by far) user of the kernel-userspace headers. If you've
never had a broken glibc, you might not realize just how important it is,
but suffice it to say, without a working glibc, pretty much your entire
system will be broken, so it's pretty important.
(FWIW, one of the ~arch glibc updates at one point failed to install its
symlinks correctly, I believe due to fighting with a new ~portage feature
as well. I was able to avoid an emergency shutdown and reboot onto my
root-bak recovery snapshot because I happened to have mc already running
in another terminal, and it has internal symlinking abilities that I was
able to use to manually create the symlinks once I figured out what
happened, but no new apps would start as they couldn't load glibc, and
most folks would have had to reboot to recovery disk/partition to fix it,
as would have I had I not had mc running. Another time an update broke
bash... that one wasn't fun, either!)
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman