Which Headers

I say the following changes need to happen

GLIBC to be built against raw kernel-headers

Everything else against the sanitized headers that I have been working on. http://ftp.jg555.com/headers

Sorry if this is a dumb question, but why does glibc need to be built against raw headers?

I've just refreshed my memory by looking at fedora, who supposedly build the toolchain correctly (well, I'm sure that's what Uli says). They build against 2.4 headers which some poor sap is tasked with keeping up to date, and they hack in an override file so that the build pretends to be on 2.6.9. This is in tune with the old recommendation to build against the kernel headers, and using raw headers has less scope for error than the fedora way.

But, there are two issues with this:

(1.) can we prove that the raw headers give a better build ? (2.) are the sanitised headers good enough for everything else ?

Looking at the detail of the last linux-libc-headers, there appear to be a lot of things that are questionable for userspace. But, the headers seem to work adequately, so maybe that part of the process is not going to be too calamitous, although I suspect resolving some of the problems will be painful [ I had a problem with kde on ppc64, it smells like a header problem, but I couldn't get anywhere trying to trace it ]

I'd love to see a reasoned explanation of why glibc needs raw headers, particularly now that so many people have built on different architectures with the old sanitised headers, without obvious problems.

The reason for building GLIBC from the raw headers, it's the recommended build method from the GLIBC folks. This also helps when we have issues to report, we at least can tell them we follow the procedures that they have specified to build correctly.

Just for clarification and the sake of keeping a record, where do you find the recommendation for this? In the documentation of the released tarball, such as the INSTALL file? Or have they said it a bit more specifically somewhere else?

In the INSTALL file of glibc-2.4 I see where it says it looks for Linux kernel headers in /usr/include or that you may specify another directory with --with-headers (nothing new here). It also says the following:

   If you're upgrading from Linux libc5 or some other C library, you
need to replace the `/usr/include' with a fresh directory before
installing it.  The new `/usr/include' should contain the Linux
headers, but nothing else.

There's this paragraph as well:

If you are installing GNU libc on a GNU/Linux system, you need to have
the header files from a 2.2 or newer kernel around for reference.  For
some architectures, like ia64, sh and hppa, you need at least headers
from kernel 2.3.99 (sh and hppa) or 2.4.0 (ia64).  You do not need to
use that kernel, just have its headers where glibc can access at them.
The easiest way to do this is to unpack it in a directory such as
`/usr/src/linux-2.2.1'.  In that directory, run `make config' and
accept all the defaults.  Then run `make include/linux/version.h'.
Finally, configure glibc with the option
`--with-headers=/usr/src/linux-2.2.1/include'.  Use the most recent
kernel you can get your hands on.

Do you have any other references you could share?

I'm proposing the following changes

This change will require 3 steps. Headers to be installed based on the headers 00.27 script.

1 - Installation of the Raw Kernel headers for the glibc build. 2 - Have glibc build against the Raw Kernel headers as recommended by GLIBC folks 3 - Installation of the Sanitized Headers

The link every one keeps asking for

http://sourceware.org/ml/libc-alpha/2003-07/msg00163.html

Book now updated to use our headers package instead of LLH. Took numerous considerations into this change.

1 - We need the testing, testing so far as been good, need a more diverse group 2 - This will get us to the new ABI for PPC MIPS and Sparc, with LLH is with the old ABI.

We also decided to use our headers to build glibc, to keep the same headers through the entire build.

We will be creating a ticket for all bug reports due to the headers and leaving it open.