Ruben Van Boxem added the comment:

Paul,

OK, I understand your point of view. As you say, there is no single "MinGW" 
community, nor a guiding body that takes these decisions. If you're not willing 
to choose one, all I can say is this: it will probably not matter which version 
you choose (all will work), only mixing them won't work.

A sound choice would be to follow the Qt Project (it's what they ship in their 
SDK):
http://doc.qt.io/qt-5/supported-platforms.html#reference-configurations
They chose the dw2/posix combo, which IMHO is the best choice all-round.
For 64-bit, the obvious one is seh/posix.
Incidentally, that's what MSYS2 people chose, and they regularly build all of 
Python with these toolchains (plus some other packages including numpy/scipy), 
see https://github.com/Alexpux/MINGW-packages/ and search for "-python-".
These python builds are done from source, do not link to msvcr100, but just 
msvcrt.dll, which is the OS component MinGW GCC links to currently and in the 
foreseeable future.

As it stands, you can easily reproduce these builds by:
1. Installing MSYS2 (download and install, see 
http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/)
2. Installing GCC (i.e. "pacman -S mingw-w64-i686-gcc" for 32-bit or "pacman -S 
mingw-w64-x86_64-gcc" for 64-bit)
3. Installing all of Python's dependencies (see e.g. PKGBUILD: 
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-python2/PKGBUILD#L14)
4. running makepkg in the directory with the python PKGBUILD with the patches 
next to it. make sure to use the "MinGW-w64 Win64 Shell" or "MinGW-w64 Win32 
Shell") that MSYS2 places in your start menu. This sets PATH to include the 
relevant toolchains and tools, much like the VS command prompts.

You can then extract the necessary dependency DLLs from the MSYS2's 
/mingw32/bin and /mingw64/bin directories so that a standalone MinGW-w64 Python 
installation can be created from that without issue. 

If you feel this qualifies as an easy, maintainable, reproducible setup, 
perhaps work can be done to integrate the large amount of patches currently 
required. Note that these patches will work with any decent and/or official 
MinGW-w64 GCC build. The time of everyone needing to build their own toolchain 
is past. Even if some people still building all kinds of cludgy variants seem 
to have missed the memo.

Note that these builds differ from the official MSVC builds (which may not be a 
bad thing: it keeps MSVC<->GCC compatibility issues arising from mixing the 
code to a minimum). Obviously, when MinGW-w64/GCC supports the UCRT stuff, this 
incompatibility can be harmoniously resolved. Until then, this seems to me like 
a good solution, and it is how everyone else is doing it (i.e. separate GCC 
builds on Windows).

If there is no interest in having a (community-supported, semi-official) 
GCC-built Python on Windows, I'm sure something else can also be worked out, 
which would include stripping the current dinosaur -mno-cygwin code which is 
what this bug was originally all about.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to