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