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.
Sometimes you need to repeat 4,5,6 (but using the full toolchain
produced in the previous run, not the minimal one obviously).
It's a good sanity check anyway ;-)
1. Seems to be a good reliable source of sanitized headers for recent
kernels. I know of no problems with the current release.
There still are problems so you're advised to use the separate kernel
headers package instead.
2. Seems to build and work out-of-the-box using the headers from step
1. I know of no problems with current release.
Binutils doesn't need any kernel headers AFAIK.
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.
configure --verbose --help
I posted the full set you currently need.
Further more, the make file may try (and fail) to make additional
things like crt0 in EXTRA_PARTS=
Don't use --with-newlib if you don't want to build newlib.
Right now it's a question of "wtf caused that to die?"
Yeah, it's a fun voyage, isn't it :-)
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.
Yeah, that's a good point. I use --enable-sjlj-exceptions to
avoid the need for those headers, but that's not enough for
building ia64-linux (it _is_ enough for all other Linux targets).
Some people advocate combining steps 3,4,5 by either cribbing a set
of headers from someone elses sysroot,
That's the "normal" procedure for building a cross-toolchain, yes.
or by fooling glibc configure in to producing them without having a
minimal cross compiler.
You should only need this if you're porting to a new target. And
then this all is the least of your troubles ;-)
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.
That's exactly what I'm doing. Feel free to take a look at my scripts:
git://git.infradead.org/~segher/buildall.git
or browse it at:
http://git.infradead.org/?p=users/segher/buildall.git
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.
Bugs happen :-)
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?
It would be nice if things were a bit easier; maybe a single configure
flag "--from-scratch" or something like that. Someone needs to create
that though.
Segher
