This is the mail archive of the
mailing list for the glibc project.
Re: Support installing headers for bootstrapping libgcc
> I don't think libgcc is the right place for that sort of detail about what
> headers are needed internally by other headers but not installed by glibc;
And I don't think glibc is the right place for much of any detail about
what building gcc requires.
A simple ideal would be that you can just build the compiler proper (no
nontrivial target libraries) and then use that to build glibc. We're
not quite there, and perhaps there are good reasons for that. But I
really think we need a fresh consideration from the ground up of what
all the tangled dependencies are and, more importantly, which are truly
1. Why do we need libgcc at all just to build glibc?
By this I mean literally to build it, i.e. not to run anything, tests
or anything else. (Take as given that anything like rpcgen was or
localedef is, i.e. where we run just-built programs as part of the
build, would be avoided somehow as we've discussed separately.)
I guess some bits of libgcc might be required to link the DSOs
themselves, depending on the machine. Can we cite what those are?
I think only the traditional libgcc fodder should really be in that
category (e.g. __muldi3). Nothing for EH should really be required,
since we use libgcc_s.so only at runtime via dlopen.
What else is there?
2. Why do we need anything from glibc just to build libgcc?
The traditional libgcc bits are pure CPU-using code.
No system headers should be required to build that stuff.
If they are, it just seems like laziness in the organization
of the libgcc code. Is there something I'm overlooking?
What else is there? Maybe libgcc sometimes wants to call abort, or
some syscall for cache-flushing or the like. Does it really need
headers for that? These things have well-established signatures,
so it can just use its own declarations.
The libgcc_s.so EH stuff needs to call dl_iteratephdr. OK, that
reasonably requires a header. But, as mentioned above, we don't
really need to build libgcc_s.so before we build libc, do we?
What else is there?
I've made it sound simple and of course I know it's actually harder than
that. But I'm pretty confident that it really doesn't need to be nearly
as hard as we've made it. I'm not convinced there truly need to be any
circular dependencies at all. So let's step back and figure out how it
really ought to be and can be.
Ideally the bootstrap procedure would be:
1. Build binutils.
This thankfully already has no target dependencies.
2. Build the compiler itself.
Today this is influenced by some things like configure checks
that change how the compiler behaves based on analysis of
libc's features. But it doesn't really have to be that way.
We can find better ways to make those configuration
3. Use that compiler to build the "basic" libgcc.
By that I mean what libgcc originally was long ago: just the
things that the compiler generates calls to for basic
operations like arithmetic and so forth. In the ideal, this
would have zero requirements of target anything (like headers),
just the compiler, the assembler, and ar.
4. Use that compiler and libgcc to build glibc.
5. Build the higher-level target libraries that come with gcc.
This includes libgcc_s.so as well as libstdc++ et al.
Let's figure out how close we can get to this ideal and what needs to
change to get us there.