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
