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

[Peter Rosin]

On 2012-04-23 13:16, Bruno Haible wrote:
> 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".

Oh, but it is wrong, it is a cross compile.  Claiming anything else
is just delusional.  You can argue that the *effect* is desirable or
not all you like, but a cross it is.

>> $ ./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.

Perhaps it is both.  But I think a warning is warranted somewhere if you
are trying to run the host code on the build machine in a cross setup.
Doing so must be considered fragile.  If the proposed change is made, there
will be no such warning, and no sign of anything abnormal going on.

Perhaps there should be a different knob so that one can have tests run
even when specifying both --build and --host, instead of relying on some
obscure property of not specifying --build?

>> 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.

It might be easier to support MinGW only when running from MSYS, compared
to also supporting it through Wine or from Cygwin or whatever.  It is e.g.
obviously not the same to do

        ./mingw-program `pwd`

from Cygwin and from MSYS.  Bottom line is that a test might look like
it works alright, when it in fact ends up all wrong in a cross setup
without --build.

>> 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.

And I think it's relevant.  Your proposed change leads to silent
differences depending on e.g. the presence of Wine.

Cheers,
Peter