bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 19111@debbugs.gnu.org
> Date: Thu, 20 Nov 2014 05:10:06 +0100
> 
> When we use the mingw toolset under MSYS{2} we are cross-compiling, as
> far as autoconf is concerned. But truth is that Emacs' `configure.ac'
> already special-cases MinGW by using $MSYSTEM and not requiring
> --host/--build, to hide the cross-compilation and make user's life
> simple.
> 
> Such special handling of the MSYS/MinGW combo assumes that the target
> architecture of the MinGW toolset being used is the same as the MSYS
> architecture retrieved by `uname'.

Yes, but it worked until now.  It's a fragile situation, I agree, but
the whole MSYS thing is fragile anyway.  IMO, we are lucky that it
works so well.

> Once we have MSYS2 supporting both i686 and x86_64, and MinGW-w64
> also supporting both architectures, the assumption is broken. I
> foresee similar problems when building for MINGW64 on a i686 MSYS2.
> 
> > Patches for nt/INSTALL are welcome.
> 
> Since we already special-case MinGW on the configure script, and fixing
> the problem there only changes how the special case is implemented
> without touching new areas, I'll very much prefer to apply the patch
> shown on my previous message and keep the nice and simple "configure &&
> make" procedure working on all cases.

OK, but at least let's keep the build/host/target triplet correct.
It's not right for us to disregard it when it doesn't fit our needs,
because the entire configure script is based on the notion that the
triplet is the starting point on which all the rest is based.

So, if we want to fix that, let's fix the triplet early on, to specify
a i686 build, and let the rest of the script do its job as usual.

Besides, I came to a conclusion that I don't understand how your
suggestion will work anyway.  AFAICT, you just replace tests based on
one wrong string (x86_64-*-*) with another wrong string (MINGW64).

Or are you saying that MSYS2 somehow magically does not give $MSYSTEM
the value MINGW64 when you configure for a 32-bit build?  If so, how
does this magic work?  Because if MSYS2 always sets MSYSTEM=MINGW64,
then your suggestion isn't going to work, is it?

More generally, how do you tell configure that you want a 32-bit build
using MinGW64 toolchain?  That requires some special compiler switches
(like -m32 or some such), no?