OK, let me recap as I understand the discussion up to now, realizing
that this is the gcc list we can really only hope to fix things, if
needed, by making changes to the gcc project. Other project will have
other priorities.
It sounds like the consensus is that bootstrapping a cross-compiler
still requires the use of inhibit_libc and for a Linux target *should*
work like this. And, apparently is does work like this for some people
for some targets, just not for everyone for everything.
1. Configure the Linux kernel and "make headers_install".
2. Configure and make binutils using the headers produced in step 1.
3. Configure and make a minimal gcc cross-compiler for the target by
getting configure to set inhibit_libc and disabling any complicating
or conflicting options such as threads and multilib not strictly
needed to build the minimal compiler. This compiler should not be
generally used because of the restrictions placed on it during the
build process.
4. Use the minimal cross-compiler produced in step 3 to configure
glibc and do "make install-headers" to get glibc headers. At this
point you should be able to delete the minimal cross-compiler, it's
job has been done.
5. Make distclean and then configure, make, and install a normal gcc
cross-compiler for the target using the glibc headers produced in step 4.
6. Make distclean and then configure, make, and install the complete
glibc header and libraries etc. for the target.
7. Use the tools produced in steps 5 and 6 to do whatever
cross-compiling project you need them for.
Now for some thoughts about this. I assume we are working with current
releases of the kernel and tool chain. There are lots of problems with
various older combinations of things, let's not go there please right now.
1. Seems to be a good reliable source of sanitized headers for recent
kernels. I know of no problems with the current release.
2. Seems to build and work out-of-the-box using the headers from step
1. I know of no problems with current release.
3. Figuring out the correct combination of --with-newlib,
--with-sysroot, and --with-headers (or --without, or =no etc.) to get
inhibit_libc set and then figuring out which of the myriad of
--with-this-that-and-the-other options can or must be disabled to get
a functional minimal compiler is a real pain in the neck. Further
more, the make file may try (and fail) to make additional things like
crt0 in EXTRA_PARTS= which require the use of "make -k" and/or manual
copying of the needed bits and pieces. It does not always work and the
failures seem to be in different places on different targets. Maybe
the make files need to be modified some depending on the configure
setting of inhibit_libc?
If this is *supposed* to work, would it be worth while having a
--force-bootstrap or some such option so that configure could force
inhibit_libc and then short circuit lots of configuration stuff and
disable everything appropriate on a per-target basis so we can
reliably generate the minimal comiler needed for the next step? With
that, additional places in the source that really need inhibit_libc
special casing would be much clearer. Right now it's a question of
"wtf caused that to die?", since bootstrapping a cross-compiler is
such a black art to most people. Also, should the inhibit_libc hack
also disable things like the unwind support that requires kernel
headers? That not scrictly libc, but --without-headers sort of assume
neither are present. It would also be nice if there were a clear
statement about what needs to be where in the headers and/or sysroot
directory structures. Or, should be just require some sort of
combined tree build in this case? In which case it would be nice if
there were a clear statement about what needs to be copied or
symlinked from where to where to make it work. I'm a bit out of my
depth since I have *not* gotten it to work for many of the cases I
have tried, yet. It's not that I'm unwilling to try and contribute
patches, but I'd like to know where we are heading, please.
Some people advocate combining steps 3,4,5 by either cribbing a set of
headers from someone elses sysroot, cobbling them together by hand, or
by fooling glibc configure in to producing them without having a
minimal cross compiler. They build their cross-compiler using these
headers and then they proceed to step 6. That's great if you are only
working with one, common, target where you can expect to find someone
to crib from or you have better luck than I did trying to understand
and fool glibc configure. In any case that leaves us as the mercy of
changes to the glibc package, and the glibc maintainers can reasonably
assume the existance of a compiler and may use that compiler to check
things like sizeof(long double) etc. so it's fragile at best to rely
on. (BTW - why do we have both -m128bit-long-double and
-mlong-double-128 options for different targets?) However, it's
probably not viable for someone trying to build 20 or so tools chains
so they can check for kernel build failure tree wide etc. And
besides, it would sure be nice if gcc would build a cross-compiler
out-of-the-box if there is no problem with some other part of the tool
chain. That does not seem to be the case for all targets at this point.
Once you get to step 6, I expect you are home free, or at least are
out of the domain off gcc and need to talk to the glibc folks for any
problems that pop up at that point.
So, that's the situation as I see it. How should things work in an
ideal world and where do we go from here? Or, are other people happy
enough with the current ecosystem and think nothing needs to change?
Steve
