Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?

[Ruben V. B. <van...@gm...>]

>
> > environment variable MSYSTEM.  So if MSYSTEM is changed to say mingw64
> > then the config.guess and config.sub scripts could be changed to
> > recognize the uname string to produce i686-pc-mingw64, x86_64-mingw64 or
> > even x86_64-w64-mingw32 which ever is preferred.  The uname string from
> > MSYS would read MINGW64_NT-5.1 if MSYSTEM=mingw64.
> >
>
> I believe MSYSTEM should be set uppercase, as setting mingw32
> lowercase do not identify properly.
>
> This change should be send upstream?
>
> > My personal preference for a config.guess return string would be
> > x86_64-w64-mingw.
> >
>
> I believe this was already established as "x86_64-w64-mingw32" ?
>
> http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS
>

Great, someone actually found the wiki!

MSYS itself is 32-bit, so having uname return something else is not quite
correct. There are other things bad about this suggestion:
1. What if you have installed x86_64-w64-mingw32-gcc, i686-w64-mingw32-gcc,
and i686-pc-mingw32-gcc, and added all three paths to MSYS's path? uname
isn't at all a correct way to determine the compiler's target, especially
when you think about cross-compilation, and (future/current) multilib.
2. The wiki states the workaround/"The Right Way" to use mingw-w64 under
MSYS.

I believe passing -host=... to configure is a small price to pay (if any)
for the functionality you get from using MSYS+mingw-w64. The MSYS package
provided by mingw-w64 (aka me in this context) is only the complete binary
set of packages conveniently packed into one. I don't feel I have the
right/will to change internal settings (of which I do not know how far these
reach) or to keep any changes up to date.

I hope you can understand my reasoning, and I'll be happy to read any
arguments against what I stated above and consider revising my opinion, but
MSYS works fine as is.

Ruben