Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: AMD64

Question On Linux-Headers And Glibc

 

 

Gentoo amd64 RSS feed   Index | Next | Previous | View Threaded


frank.peters at comcast

Feb 14, 2010, 8:45 PM

Post #1 of 5 (1373 views)
Permalink
Question On Linux-Headers And Glibc

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?

I would like to get a few more things cleared up also. I maintain
a stock Linux kernel myself rather than rely on the kernels that
are available in the portage tree. Currently, I am using kernel-2.6.33,
and its source tree is found in /usr/src/linux. (My package-provided
file has the line "sys-kernel/vanilla-sources-9999" to prevent any
rumblings from portage.)

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?

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?

These are minor points but it is always better to understand what's
happening than not understand.

Frank Peters


realnc at arcor

Feb 14, 2010, 11:05 PM

Post #2 of 5 (1341 views)
Permalink
Re: Question On Linux-Headers And Glibc [In reply to]

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


1i5t5.duncan at cox

Feb 15, 2010, 1:45 AM

Post #3 of 5 (1341 views)
Permalink
Re: Question On Linux-Headers And Glibc [In reply to]

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


frank.peters at comcast

Feb 15, 2010, 5:33 AM

Post #4 of 5 (1426 views)
Permalink
Re: Re: Question On Linux-Headers And Glibc [In reply to]

On Mon, 15 Feb 2010 09:05:58 +0200
Nikos Chantziaras <realnc [at] arcor> 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


frank.peters at comcast

Feb 15, 2010, 5:42 AM

Post #5 of 5 (1338 views)
Permalink
Re: Re: Question On Linux-Headers And Glibc [In reply to]

On Mon, 15 Feb 2010 09:45:07 +0000 (UTC)
Duncan <1i5t5.duncan [at] cox> 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

Gentoo amd64 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.