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

[Stephen M. Kenton]

Hello all,

Several years ago in the gcc 3.3 time frame I looked into building cross 
compilers using the current versions of gcc, glibc etc. for a number of 
different systems.  I quickly found that it was a quagmire.  I inquired 
of this list at that time and was told that the glibc hack was 
problematic and that things would not be fixed in gcc 3.4 but might get 
better by gcc 3.5 (which eventually became gcc 4.0).  I worked around my 
need at that time and went on to other things.  Recently out of 
curiosity I dug out the problem and took another look.  Except for the 
fact that the Linux kernel build system now supports headers_install to 
provide a reliable set of sanitized header, not much seems to have 
changed.  I realize that there are various "solutions" for specific 
platforms.  Dan Kegel's excellent crosstool and the cross-lfs website, 
for example, are testaments to the people who have labored to circumvent 
this problem.  However, the question remains, why is the problem still 
there to be circumvented?  Is there some secret opposition to easy use 
of these tools, is there some law of nature that prevents them from 
building, is there some good technical reason that is hard to implement, 
or has it just not been a big enough pain for anyone to beat it into 
submission?  As it stands currently, it looks like gcc needs both the 
kernel (for unwind support) and glibc  (for generic C reasons) headers 
*for the target* to build  a cross compiler for that target, but glibc 
needs a functioning cross compiler for that target before it will even 
configure so you can try to "make install-headers".  Mean while, back at 
the ranch, the inhibit_libc hack does not seem to be implemented 
everywhere needed for a successful build and the gcc configure seems to 
have a curious need for the --with-newlib  flag to really mean we want 
inhibit_libc as well as handling with_sysroot and with_headers rather 
differently. (See the fragment below from gcc 4.2.1) As an aside, I 
suspect that there are subtle assumptions that the build/host glibc 
headers are the same as the target glibc headers in some respects.  Way 
back, I was trying to cross compile on Solaris using a complete self 
hosting gnu tool chain and I saw some very strange failure.  In the 
current experiment I am using a more-or-less up to date Linux system, 
but if/when building a cross compiler works I could resurrect the 
Solaris test environment to check for portability issues of that type.  
For now I'm just looking at current Linux build/host/targets.

So, my open questions to the list are, what is/should be the preferred 
way to bootstrap a cross compiler/glibc environment?
What needed to be done to get there from here?  Does the inhibit_libc 
hack need to be extended, ripped out and replaced, or just better 
documented?  I will follow this discussion on the gcc mailing list 
archive since I'm not subscribed, but I'm willing to test stuff if 
anyone wants me to.  Or, if it really does work currently and I'm just 
an idiot, could some kind soul hit me with a clue-bat and point me to a 
descriptions of the solution.

# inhibit_libc
 
# If this is using newlib, without having the headers available now,
# then define inhibit_libc in LIBGCC2_CFLAGS.
# This prevents libgcc2 from containing any code which requires libc
# support.
inhibit_libc=false
if { { test x$host != x$target && test "x$with_sysroot" = x ; } ||
       test x$with_newlib = xyes ; } &&
     { test "x$with_headers" = x || test "x$with_headers" = xno ; } ; then
       inhibit_libc=true
fi

Thanks - Steve