On 09/09/2010 09:26 AM, Volker Armin Hemmann wrote:
On Thursday 09 September 2010, walt wrote:
And the only reason to re-compile an existing glibc is if the linux kernel
headers change. I always re-compile glibc when the linux kernel headers
change...
hm, I never recompile glibc after a header update.... or anything else....
I never did either until recently, when I started playing with vbox from
its svn repository in addition to tracking the latest from Linus.git.
Until then I had no idea how often the kernel devs break things by changing
kernel data structures and system calls without notice.
That's significant for projects like vbox because they (apparently) use
kernel services directly without going through libc like everybody else.
I'm assuming that's true because the vbox code insists on using the kernel
headers from the kernel that is actually running at the time. (Hence, the
vbox code breaks every time Linus changes something important.)
User space programs aren't supposed to poke at the kernel directly (unlike
the vbox kernel module) but go through libc to use kernel services.
So, how to avoid breaking glibc with every new kernel update?
The solution, for better or worse, has been to maintain an independent set
of kernel headers that change only when new kernel user-space features are
added or obsolete ones deleted -- not very often -- and those are provided
to user-space programs through libc.
So, I'm *assuming* that gentoo devs release an update for the kernel-headers
package when some user-space kernel service has been added or deleted.
(Device drivers and other kernel modules get broken much more often than
that.)
If my assumption is correct, then programs linked against libc (lots) won't
actually see the changes until libc is re-compiled against the new headers.
And, most of the time it doesn't matter because existing programs aren't
using any brand-new kernel services (yet).
Corrections are welcome, as always.
