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