Fix building extensions with MinGW for Python 3.5 #8355
Conversation
|
|
||
| # monkey-patch cygwinccompiler with our updated version from misc_util | ||
| # to avoid getting an exception raised on Python 3.5 | ||
| distutils.cygwinccompiler.get_msvcr = get_msvcr_replacement |
There was a problem hiding this comment.
It has been a long time since I've seen something relevant in that area, but the MinGW adapter uses the CygWin adapter as a base, so in this regard it is more like a shackle that needs to be dusted and polished. (I'll try to submit these changes upstream to CPython as well, but it'll take some time until those changes can be relied upon to be in the base distribution)
|
Not my area. ISTR that there were problems with mingw32, at least our generated binaries were buggy. @rgommers @matthew-brett Comments? |
Notice that this fix is more intended for third-party extensions that needs f2py, than for building NumPy itself. (maybe the label should have been |
There are three concepts in the C runtime library used by Python on Windows (from the Microsoft Visual C compiler); the internal build number (e.g. 0x1600), the major version of the runtime (e.g. 10.0), and the name of the link library of the runtime (e.g. msvcr100). This patch separates getting these three values into separate functions so that other code can be relieved of parsing the string return value of the msvc_runtime_library function.
Python 3.5 is built against vcruntime140 instead of msvcrXXX, and the internal version number reported by the version string is 1900. This cause building extensions to fail, complaining about a missing compiler. This patch adds the latest runtime library to the list.
CygwinCCompiler has its own test for the C runtime library which raises an error if the version extracted from the version string does not match a pre-defined list. The runtime for Visual Studio 14 (aka 2015) which is used to build Python 3.5 is not on this list. As this call is made in the constructor of the base class, it must be monkey-patched to get around.
The MinGW compiler adapter assumes that the C runtime library that Python was built with has the name msvcrXXX. This is incorrect for Python 3.5 and later. (The name of the runtime is now vcruntimeXXX). This patch removes parsing of the hardcoded pattern and replaces it with calls to new functions in misc_util that returns the desired values directly, isolating the hardcoding to that module.
|
I streamlined the commits to follow a more logical progression; the end result should be the same (sorry to anyone who already pulled the branch). |
|
I'm going to put your two PRs in, but have no idea if they are correct, nor do I know anyone else using that environment at the moment. Which is to say that the onus is on you to deal with any problems that arise ;) Could you add a comment to |
MinGW can be used to build extensions, but will most likely fail for extensions that uses the runtime extensively. This is just a band-aid until Mingwpy is fully functional for calculation code written in Fortran.
I wouldn't quite describe myself as a user of this environment, to be honest. This was more a stunt to get some code working for a colleague whose MacBook otherwise would have suffered from thermal melt-down, and all there was available was a Windows machine :-)
Have done so, adding links to the issues in general if one attempts to do something more fancy. Hopefully, this will be obsoleted once Mingwpy is operational. |
|
Thanks @rolk . |
On Windows, with Python 3.5; if using the setting
compiler=mingw32(in for instancesetup.cfg) and then building withpython3 setup.py develop, the build will end with the error message:because the version string that is compiled into Python 3.5 indicates that it is built with Microsoft Visual Studio 2015, and this is unknown to the list coded into the distutils module.
This is unfortunate, as it precludes using the easily accessible MinGW distribution's free GNU Fortran compiler to build extensions.
This changeset adds support for the runtime used in Python 3.5. It is tested with WinPython 3.5.2.2 and MinGW 6.2.0 (win32, seh, rt-v5). It should be noted that the resulting .pyd still has a dependency on MSVCRT.DLL (and not VCRUNTIME140), but so does PYTHON35.DLL indirectly through WS2_32.DLL.