Mailing List Archive

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.


> 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).

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
/usr/include/linux.

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

On Mon, 15 Feb 2010 09:05:58 +0200
Nikos Chantziaras <realnc@arcor.de> wrote:

>
> 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).
>

This is the information that I needed. Now it's clear what is
happening.

Frank Peters

On Mon, 15 Feb 2010 09:45:07 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:


> 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.
>

As an aside to this issue, it should be noted that the extreme importance
of glibc is what has inspired the "GNU/Linux" campaign. That is, many
people strongly believe that Linux systems should be referred to as
"GNU/Linux" because a Linux system is much more than just the Linux kernel.
The GNU C libraries are equally important. The argument is much more
than empty rhetoric.

Frank Peters