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 11:07:14 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> I have to say that I still don't like the way of determining the host
> platform on MinGW builds, because we are setting $host and $canonical
> to a value (the compiler's target) that is not guaranteed to be
> canonical (and in fact is not canonical in the cases I've tried, see
> below).

Why do you think it isn't canonical?  For that matter, what is your
definition of "canonical" in this context?

> The following table shows the canonical host (as given by
> 'build-aux/config.guess') and gcc target taken from the 5 different
> build environments for MS-Windows I know of:
> 
> #  MSYS type     $MSYSTEM   canonical host      gcc target
> -  -----------   --------   -----------------   ------------------
> 1  MSYS          MINGW32    i686-pc-mingw32     mingw32
> 2  MSYS2-32bit   MINGW32    i686-pc-mingw32     i686-w64-mingw32
> 3  MSYS2-32bit   MINGW64    i686-pc-mingw64     x86_64-w64-mingw32
> 4  MSYS2-64bit   MINGW32    x86_64-pc-mingw32   i686-w64-mingw32
> 5  MSYS2-64bit   MINGW64    x86_64-pc-mingw64   x86_64-w64-mingw32
> ------------------------------------------------------------------
> 
> As you can see, our problem is only in the environments 3 and 4, where
> the first part of the canonical triplet (CPU in CPU-VENDOR-OS) is not
> what we want.

Verification of the canonical configurations is the job of the
config.sub script.  In this case, it considers all the "gcc target"
strings valid and outputs them intact, with a single exception: it
replaces "mingw32" with "i386-pc-mingw32", which is correct because
the mingw.org's development toolchain targets that host.

I'm guessing you somehow think that the "pc" part must be there
verbatim.  But that is incorrect: it is just the default value of
MANUFACTURER when the configuration type supplied "by other means"
doesn't provide a MANUFACTURER.  Since the *-w64-*-mingw32
configurations do provide MANUFACTURER, there's nothing wrong with
them, and they cannot cause any harm, AFAIK.

> But note that this problem is easily fixable: the CPU we want can be
> deduced from the OS part of the triplet:
> * mingw32 --> i686
> * mingw64 --> x86_64

I don't think we need that, since what we have now uses perfectly
valid canonical configuration types.  In any case, if you still are
unconvinced, the way to fix this is to submit patches for config.sub,
so that it does this mapping automatically.  Its that script's job,
not ours.

Thanks.