Why is building a cross compiler "out-of-the-box" always broken?

[Steve Kenton]

Thanks, I git cloned buildall and it sure looks simple (now that you 
have made it work) :-!
Although, that combination of options was not exactly obvious at first 
glance.  Time to re-read
all the config --help stuff.

I'll try it on my build system at work tomorrow and see what bites me 
next. I expect that I am
having old nightmares from when I was trying to do this under Solaris 
and made it harder than
I needed to on a Linux host.  Apparently, I'm not the only one who got 
lead astray though.

Thank again - Steve

Segher Boessenkool wrote:
>>> 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