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

> Date: Sat, 29 Nov 2014 20:23:31 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, 19111@debbugs.gnu.org
> 
> As I see it, MSYS2 (either its 32 or 64-bit version) comes with two
> ways of invoking bash: mingw32_shell.bat and mingw64_shell.bat.
> 
> IIUC, this gives the user two _build_ environments: one tuned for
> building 32-bit MinGW programs and other for 64-bit.

That's just a convenience vehicle.  A user can invoke a 32-bit or a
64-bit compiler without running those batch files.

> So, if I enter the 32-bit _build_ environment and I build Emacs with a
> plain 'configure && make', I'd expect it to work out of the box.  But
> as we've seen, it doesn't.  Why? -> Because the canonical host
> platform (picked up by default) has a wrong CPU.  And why? -> Because
> the canonical _build_ platform picked (up by default) has a wrong CPU.
> And why? -> because 'uname -m' gives 'x86_64' in a build environment
> that pretends to be tuned for 32 bits.

You may wish to re-read the beginning of this bug.  There, I explained
that using a MinGW64 compiler to produce a 32-bit binary is a kind of
cross-compilation, as far as a toolchain running on a 64-bit machine
is concerned.  Therefore, we could require the users that do such a
thing to provide explicit host at configure time.  Óscar wanted to be
nicer to MinGW64 users, so we went one more step towards them.

But it would be IMO wrong to develop a theory out of that.  In theory,
they should provide a configuration type, period.  Neither MSYS2 nor
its 'uname' can do that job.  We tweaked our configury because we
decided to do so, and as long as it works, I see no need for pushing
that any further.