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

["Óscar Fuentes" <ofv@wanadoo.es>]

Dani Moncayo <dmoncayo@gmail.com> writes:

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

One places /mingw32/bin on the PATH, the other places /mingw64/bin on
the PATH. They also set MSYSTEM. That's all.

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

`uname' has nothing to do with the toolset you are going to use.

The scenario is similar to building on a x86_64 GNU/Linux box targeting
i686. You can build and *run* the software on 32 bit mode on that same
machine. Certainly, nobody expects that `uname' changes its output
depending on how do you plan to build the software.

Usually, the user would be required to explicitly declare their intended
host platform when there is a mismatch of MSYS2 arch/MinGW-w64 arch.
What I submitted was a hack that exploits an MSYS2 idiosyncrasy for
relieving the user from that work and, more important, avoiding a
puzzling build error. You now propose to translate the hack to MSYS2
`uname'. That's going too far, IMO.