Dammit, I'm cross-compiling, but gcc's configure script pulls inbogus files from /usr/include, and hangs when it runs output of CC

[Dan Kegel <dank at kegel dot com>]

I have now run into two places where I can't build gcc
properly because autoconf2.13 doesn't cache ac_cv_prog_cc_cross:
building on cygwin (see http://sources.redhat.com/ml/crossgcc/2002-08/msg00112.html,
in which running the output of CC causes a hang)
and now building an x86 -> x86 cross compiler
(see http://archive.linuxfromscratch.org/mail-archives/lfs-support/2003/03/0269.html,
in which fixinc.sh pulls in stuff from /usr/include that doesn't make
sense in the context of the glibc being built for the target system;
but see http://linuxfromscratch.org/~greg/pure_lfs.txt for patches
and a build procedure to work around this).  (I'm building an x86 -> x86
cross compiler simply as a way of making it easier for me to test
my cross-toolchain build script as I start adding remote regression test support.)

In both cases, building gcc would be much easier if there were a way to
simply and effectively tell autoconf that CC is a cross compiler.
Oddly, there is no way to do this.
ac_cv_prog_cc_cross is computed anew every time AC_PROG_CC_WORKS
(perhaps via AC_PROG_CC) is run.  The right place to fix this
is to edit autoconf-2.13's acspecific.m4.  (It's tricky; probably
AC_PROG_CC_WORKS should only run AC_TRY_COMPILER if one of
ac_cv_prog_cc_{works,cross} is undefined, and use its results
to set only the undefined one(s).)  To make this fix stick, it'd
have to be done on the gcc project's private copy of autoconf-2.13,
whereever that is.  (Anyone know exactly what version they use?)

I tried looking at what autoconf-2.5x does for this, but it was not
clear on inspection how things worked there.  I suspect it suffers from
the same problem.  In any case, it seems clear that future versions
of autoconf should absolutely, positively give the user a way to tell
autoconf to act as if CC (or CXX, or F77) is a cross-compiler
and to avoid running any programs generated by CC and its ilk.

There are also things in gcc's */configure.in that need changing.
Suspicious lines include anything that compares $build to $host,
and anything that checks $with_cross_host:

[gcc-3.3]$ egrep 'cross_host|if.*test.*build.*=.*host|if.*test.*host.*=.*build' */configure.in
boehm-gc/configure.in:if test -n "${with_cross_host}"; then
boehm-gc/configure.in:if test -n "$with_cross_host" &&
boehm-gc/configure.in:   test x"$with_cross_host" != x"no"; then
gcc/configure.in:if test "$host_xm_file" != "$build_xm_file"; then
gcc/configure.in:if test x$host = x$build
gcc/configure.in:if test "${build}" != "${host}" && test "x$enable_nls" = "xyes"; then
gcc/configure.in:if test x$build != x$host
gcc/configure.in:if test x$host != x$build
libffi/configure.in:if test -n "$with_cross_host" &&
libffi/configure.in:   test x"$with_cross_host" != x"no"; then
libiberty/configure.in:if test -z "${with_cross_host}"; then
libjava/configure.in:if test -z "${with_cross_host}"; then
libjava/configure.in:   if test x"$build" != x"$with_cross_host" \
libjava/configure.in:   if test x"$build" = x"$host"; then
libjava/configure.in:if test -n "$with_cross_host" &&
libjava/configure.in:   test x"$with_cross_host" != x"no"; then
libstdc++-v3/configure.in:# configure script will pass the "real" host as $with_cross_host.
libstdc++-v3/configure.in:if test -n "$with_cross_host" || test x"$build" != x"$host"; then
libstdc++-v3/configure.in:  if test -n "$with_cross_host" && test x"$build" != x"$with_cross_host"; then
zlib/configure.in:if test -n "$with_cross_host"; then
zlib/configure.in:if test -n "$with_cross_host" &&
zlib/configure.in:   test x"$with_cross_host" != x"no"; then

All of these should probably be checking some new variable
$ac_cross_compiling, which should be overridable via the cache
or the environment.   Or perhas the existing variable ac_cv_prog_cc_cross
should be designated for this (though it's vanished in later
versions of autoconf, not sure what it was replaced with).

Assuming pure_lfs.txt's build procedure isn't a complete fix,
I'd be happy to fix this for real if folks agreed it was a good idea.
(Last time I proposed a fix, for just the cygwin version of the problem,
it was turned down, and that's fine -- it was only a small part of
the real problem.)

Similar problems exist in glibc's configure script, but let's tackle
one thing at a time.

I'm posting this first on crossgcc to get feedback, and find out
if someone else has already addressed this.  Maybe after
the idea's ripened, I'll take it to the autoconf and/or gcc lists.
Comments welcome.
- Dan

--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com