This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |