Linux API headers

Dan Nicholson dbn.lists at
Mon Jul 9 12:21:12 PDT 2007

On 7/9/07, Dejan Čabrilo <dcabrilo at> wrote:
> If I try to do:
> make mrproper
> make headers_check
> make INSTALL_HDR_PATH=/usr headers_install
> the system goes to hell, glibc becomes unusable, compilers fail sanity
> checks, etc, and I can't compile anything (thanks god for jhalfs).

We should probably fix this some better way. make headers_install does
a "nice" thing before installing the headers. It essentially does `rm
-f $(INSTALL_HDR_PATH)/include/*.h'. So, if you run it twice using the
commands in the book, you will wipe out /usr/include. The book cheats
by assuming your going to do linux-headers, then glibc, then neither

Try replacing the headers_install command with these two:

make INSTALL_HDR_PATH=dest headers_install
cp -rv dest/include/* /usr/include

> So, my questions are:
> 1a) What does the warning in the SVN book mean by "the ones against
> which Glibc was compiled ... the sanitized headers from this Linux
> kernel tarball"?

Your C libraries need to know some system specifics to get the
interfaces to the kernel correct. If you later change the kernel
headers in /usr/include, you may be advertising interfaces that your C
libraries don't know about or thinks are different. This could cause

> 1b) Why can't I reuse what is installed by make headers_install target?
> I.e. why did "make headers_install" work in chapter 6, and it doesn't
> work after everything was installed (I can't compile anything anymore)?

Bad packaging in the kernel.

> 2) Do those headers have to match the version of the kernel in use? What
> happens if they don't? I suppose I would have to rebuild glibc, but
> would other software be affected by headers change if glibc remained the
> same?

The running kernel doesn't have to match. The version should be
greater than or equal to those of the headers. This assumes that the
kernel API is stable moving forward, so that running 2.6.21 works even
if you have older kernel headers in /usr/include.

The opposite is not necessarily true. If you used 2.6.21 headers and
then tried to run a 2.6.16 kernel, you could have an application
trying to use syscalls that didn't exist back then, for instance.

> Whoever got this far gets a beer next time they are in Belgrade :) I
> hope this all makes some sense...

I hope that helps. Send that beer to Seattle, my trips through
Belgrade are scarce.


More information about the lfs-support mailing list