[lfs-support] Headers in the system's include directory. Still Confused.

Andrew Benton b3nton at gmail.com
Fri Feb 24 13:03:17 PST 2012


On Fri, 24 Feb 2012 14:47:07 -0600 (CST)
alupu at verizon.net wrote:

> So, some of the questions kicking around in my head, for anybody who'd care to
> take the time to enlighten me on:
> 
> Q1.  Was I supposed to move the 'linux-x.y.z/include/' files to
>  '/usr/include/' immediately after I installed Glibc?

No.If you're not sure, just do what the book says.

> Q2.  Am I supposed to move the 'linux-x.y.z/include/' files to
>  '/usr/include/' each time after I install a new kernel?

No. You should leave the kernel headers in /usr/include as they were
when you installed glibc.

> Q3.  Which is the "system's include directory" - the '/usr/include/'?

Yes

> Q4.  "sanitised headers" are those in this (?) Linux kernel tarball
>      against which Glibc was compiled?
>      Glibc is compiled at a certain point in time.  "this" kernel
>      varies almost daily, according to the LFS book and reality.

Fair enough. New kernels have new features but they should all support
the features offered by the headers you installed before glibc. The
risk is that if you install new kernel headers into /usr those files
will offer new features that glibc (compiled against the old headers)
won't support. Things could break and before you know it you're using a
live CD to start again.

> Q5.  What's the "raw kernel headers"?

The *.h files in the kernel source.

> Q6.  What's the "other kernel sanitized headers"?

How long's a piece of string? That could mean anything.

> Q7.  Is there a difference between "sanitised" and "sanitized" headers?
>      (this is _just a joke_ - so bear with me, I've been in a silly mood
>      once I saw 'udev-181' run so smoothly)

The raw headers in the kernel source define a lot of functions. Some of
them are private to the kernel and some a functions that the kernel
offers to userspace. When the kernel headers are sanitised the private
stuff is removed leaving only the public API interface.

Andy



More information about the lfs-support mailing list