Re: [PATCH] remove warning for --host without --build

[Bruno Haible]

Peter Rosin wrote:
> $ uname -mo
> i686 Cygwin
> $ cat << EOF > configure.ac
> AC_INIT([cross-test], [0.1])
> AC_PROG_CC
> AC_OUTPUT
> EOF
> $ autoconf
> $ ./configure --host=i686-pc-mingw32
> ...
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.exe
> checking for suffix of executables... .exe
> checking whether we are cross compiling... no   <<<<<<<<<<<WRONG<<<<<<<<<<<<<<

So, in this case, configure has detected that it can run programs,
and therefore AC_RUN_IFELSE invocations will run the test program.
This is more reliable than relying on the 4th argument of AC_RUN_IFELSE,
which is most often a (pessimistic or optimistic) guess.
Therefore this outcome of $cross_compiling is DESIRABLE, not "wrong".

> $ ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin
> ...
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.exe
> checking for suffix of executables... .exe
> checking whether we are cross compiling... yes  <<<<<<<<<<CORRECT<<<<<<<<<<<<<

So, in this case, specifying --build had the consequence that
AC_RUN_IFELSE will not attempt to run programs. This ought to be documented.
Find attached a proposed doc patch.

You call this outcome "correct", I call it UNDESIRABLE IN GENERAL.

> And, follow up problems with this difference is that e.g. the line ending
> convention used by MinGW executables are different from Cygwin and can
> easily cause testsuite failures when comparing text.

Of course when you a mingw program that does a 'printf ("\n");' it will
produce newlines as CR/LF rather than as LF. Autoconf can do nothing about
that. Either you fix the test suite to support mingw (which I've done for
gnulib and gettext, for example), or you ignore the test suite results,
or you don't run the test suite at all.

> Another potential
> problem can be found in the Automake testsuite which attempts to build
> an executable that outputs on fd 9, runs the executable and tries to read
> that output, something which I don't think is possible with MinGW
> executables.

True, native Windows executables communicate only via fd = 0, 1, 2.
Again, this is nothing Autoconf can do about.

> It's simply not a good idea to assume that you can run all programs just
> because you can run a very simple one

Sure it is possible to write non-portable code and non-portable unit tests.
But this is irrelevant to a discussion about --build and --host.


2012-04-23  Bruno Haible  <address@hidden>

        doc: Mention an effect of --build on AC_RUN_IFELSE.
        * doc/autoconf.texi (Specifying Target Triplets): Mention another
        effect of --build.

--- doc/autoconf.texi.orig      Mon Apr 23 13:14:45 2012
+++ doc/autoconf.texi   Mon Apr 23 13:12:07 2012
@@ -21747,6 +21747,10 @@
 @item address@hidden
 the type of system on which the package is being configured and
 compiled.  It defaults to the result of running @command{config.guess}.
+Additionally, when @code{--build} is specified and is different from
+the value of @samp{--host}, @code{AC_RUN_IFELSE} invocations will
+execute the @var{action-if-cross-compiling} rather than run the test
+program.
 
 @item address@hidden
 the type of system on which the package runs.  By default it is the