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

[Segher Boessenkool]

>> 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