[issue12641] Remove -mno-cygwin from distutils
Ruben Van Boxem added the comment: I can confirm the option has been removed. For those that don't want to believe a random person's comment on a bugtracker, here's the commit: http://repo.or.cz/w/official-gcc.git/commit/2637551aa9314c46cf4205d435ab5e8944e9ac8a The changelog is a bit cryptic, but note the last two items "removing documentation from removed option". -- nosy: +rubenvb ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Ruben Van Boxem added the comment: > Does anyone have more official documentation? The commit I linked to has the full option removal at October 7 2010 (see the fifth item in the changelog entry). Any GCC (major) version released after that will have it completely removed. Deprecation happened (according to the first doc change mentioning this option as being deprecated) on 2009-03-25: http://repo.or.cz/w/official-gcc.git/commit/6609be22531f447aeddbb3f670ad7883036cb23f It looks like GCC 4.4 and up have this change in them, by looking at their commit logs. Anyone using GCC 4.3 on MinGW should be shot (but that's just my humble opinion, rather radical I admit ;-) ) Note this has really nothing to do with current Cygwin or the cygwin platform; MinGW was part of the Cygwin source for a long time, and every MinGW compiler was burdened to search the Cygwin header and lib paths. These commits fixed that problem. MinGW(-w64) is a native compiler for Win32 just as MSVC is. Links to msvcrt.dll and has no POSIX translation/compatibility layer like the Cygwin DLL. May I ask for a reconsideration to commit a fix for this for Python 2.7 at least? With the version check it doesn't hurt anyone, instead it helps prevent further confusion and support requests on the MinGW side. Distutils pop up everywhere, and the projects depending on them rely on them working correctly. Thanks -- ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Ruben Van Boxem added the comment: Has anyone looked at this? I'm trying to build gdb with Python enabled with mingw-w64 (Python 2.7.1 with manually created import libraries), but have to manually define MS_WIN64 in the CFLAGS. The patch only does what's right (i.e. define a macro that should be defined). David has nicely explained what needs to be done to reproduce the issue. Thanks! -- nosy: +rubenvb ___ Python tracker <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Ruben Van Boxem added the comment: Checking for a compiler's file name is stupid. Native Windows gcc is just "gcc.exe", Cygwin native GCC is also "gcc". Some have a lot of toolchains in PATH at the same time. That's not the right way to handle this kind of thing. -- ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Ruben Van Boxem added the comment:
Paul,
Thank you for your serious take on the issue.
I'm Ruben, a long-time contributor and 3-ish year toolchain builder for
MinGW-w64. I originally helped patching Qt 4.5/4.6 so that it worked with
MinGW-w64 on 64-bit Windows.
I can help liaison between you and the MinGW-w64 project, and point you towards
stable, well-maintained MinGW-w64 builds. Perhaps we can discuss all the nitty
gritty details elsewhere (or I can continue here of course), so we can get this
straightened out.
In short, this is the story:
- MinGW.org is the "old" MinGW project, which has become pretty stale and is
behind in s many aspects that it isn't even funny anymore (mostly new
Windows APIs, DirectX support, and C++11 threading support is lacking).
MinGW-w64 is a clean-room implementation that was released into the public
domain, and by now included in all (I repeat, all) major Linux distro's as a
cross compiler. Arch, Debian/Ubuntu, Fedora/Redhat etc. all provide a MinGW-w64
based cross-compiler. A complete list of MinGW-w64 features can be found on the
web page: http://mingw-w64.yaxm.org/doku.php
- TDM is a famous name in the MinGW world because he provided a high quality
toolchain with installer when MinGW.org lacked in providing the new GCC 4.
Unfortunately, he applies (perhaps useful) patches which break binary
compatibility with upstream GCC. Since my toolchains (first uploads in
September of 2010, last one in June 2013), and later with the MinGW-builds
toolchains which are now installable through the MinGW-w64 website directly
(and shipped with Qt), there is really no reason to go look elsewhere for
toolchains. The MSYS2 project also provides numerous binary packages and I
think almost exactly the same toolchains within their environment. The official
MinGW-w64 installer can be found here:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe
(it might occasionally complain it cannot download repo.txt, that's a
Sourceforge redirect error thing that's proving might hard to fix, in any case
you can also find the toolchains directly below)
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/
- There are several ABI incompatible variants, explained nicely on the Qt wiki:
http://wiki.qt.io/MinGW-64-bit#Exception_handling:_SJLJ.2C_DWARF.2C_and_SEH
http://wiki.qt.io/MinGW-64-bit#GCC_Threading_model_.28posix_vs_win32.29
This is a choice you'll have to make. The greatest compatibility is offered by
the "posix threading" (which gives C++11 support) and 32-bit sjlj and
64-bit seh variants. The 32-bit-dw2 provides a bit more juice in exception
heavy code, but has the caveat that exceptions cannot be thrown across
non-GCC-built code. The 32-bit dw2 variant is also what works with Clang, and
is what is delivered in MSYS2 when installing the 32-bit toolchain. Since the
32-bit sturctured exception handling Borland Patents have expired, maybe a new,
32-bit seh version will emerge, but I have heard nothing concrete towards this
direction.
- The MSYS2 project also provides GCC-built Python binaries, which of course
needs quite heavy patching. These patches and build scripts can be found here:
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python2
- the -mno-cygwin option is really a dinosaur, and should be thrown into a
deep pit, buried, and forgotten. Cygwin provides MinGW-w64 cross-compilers
({x86_64,i686}-w64-mingw32-gcc) which work in exactly the same way as a
Linux->Windows cross-compiler. The official Windows binaries are just "gcc" and
work as any native compiler on Linux.
I hope this provides you with much of the information you need. If anything is
unclear (I wrote this up in like ten minutes) or you need some concrete help
figuring some things out, feel free to contact me directly or through the
bugtracker.
I sent an email to the MinGW-w64 public mailing list (subscription needed to
post though, otherwise your message will be lost in the review queue) stating
your and my intentions and current state of affairs:
http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CALc40c_p56PAg8mfPyoUvAKWsqn0PBYQmgQW_qFMcRupof8wGg%40mail.gmail.com/#msg34124287
Ruben
--
___
Python tracker
<http://bugs.python.org/issue4709>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
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 <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
