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
