classification
Title: Unknown MS Compiler version 1900
Type: behavior Stage: resolved
Components: Distutils, Windows Versions: Python 3.5
process
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: Ateik Al-Zehla, Matt.Hickford, Sam Miller, Tod Haren, anthonypjshaw, cheryl.sabella, dstufft, eric.araujo, hanbaj, marcelotduarte, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords: patch

Created on 2015-09-27 22:17 by Matt.Hickford, last changed 2019-05-06 22:19 by anthonypjshaw. This issue is now closed.

Files
File name Uploaded Description Edit
patch.diff Matt.Hickford, 2015-09-28 10:35
Messages (16)
msg251730 - (view) Author: Matt Hickford (Matt.Hickford) * Date: 2015-09-27 22:17
Hi distutils. I previously used compiler=mingw32 with success. Today I installed Visual Studio 2015. Now compiler=mingw32 gives me an error

File "c:\python35\lib\distutils\cygwinccompiler.py", line 86, in get_msvcr
    raise ValueError("Unknown MS Compiler version %s " % msc_ver)
ValueError: Unknown MS Compiler version 1900

Any ideas? I don't understand why what msvc I have installed affects build with mingw32
msg251758 - (view) Author: Matt Hickford (Matt.Hickford) * Date: 2015-09-28 10:35
Here's a patch that helped on my computer

On 28 September 2015 at 00:29, Zachary Ware <report@bugs.python.org> wrote:

>
> Changes by Zachary Ware <zachary.ware@gmail.com>:
>
>
> ----------
> components: +Windows
> nosy: +paul.moore, steve.dower, tim.golden, zach.ware
> type: crash -> behavior
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue25251>
> _______________________________________
>
msg251971 - (view) Author: Matt Hickford (Matt.Hickford) * Date: 2015-09-30 21:15
I'm not sure what the correct analogue of msvcr100 is for Visual C++ 14.0. "msvcr140.dll no longer exists" http://blogs.msdn.com/b/vcblog/archive/2014/06/03/visual-studio-14-ctp.aspx

        elif msc_ver == '1600':
             # VS2010 / MSVC 10.0
             return ['msvcr100']
        elif msc_ver == '1900':
msg251973 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-09-30 21:57
There isn't one. MinGW doesn't support building with the UCRT yet, so you'll need to link to a different version of the library and hope that it works (or test/fix the extension).
msg254687 - (view) Author: Ateik Al-Zehla (Ateik Al-Zehla) Date: 2015-11-15 12:30
how to apply patch file : patch.diff ? plz help
msg255113 - (view) Author: Matt Hickford (Matt.Hickford) * Date: 2015-11-22 22:17
Hi Ateik. Find cygwinccompiler.py on your computer and copy the patch to
the same folder. Then run the command `patch < patch.diff`. It that doesn't
work, just open both files in a text editor and copy and paste the lines to
the right place, you'll work it out.

It may or not solve your problem.

On 15 November 2015 at 12:30, Ateik Al-Zehla <report@bugs.python.org> wrote:

>
> Ateik Al-Zehla added the comment:
>
> how to apply patch file : patch.diff ? plz help
>
> ----------
> nosy: +Ateik Al-Zehla
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue25251>
> _______________________________________
>
msg255384 - (view) Author: Ateik Al-Zehla (Ateik Al-Zehla) Date: 2015-11-25 20:31
thanks Matt for your replay. But I copied the lines to cygwinccompiler.py and it didn't work. and it pretend as there is no change happened to the file. 

To see if the execution goes through the code I changed message if raise ValueError to "God Help Me %s " instead of  "Unknown MS Compiler version %s "

I saved the file, and it looks fine in the Editor.
but when I executed the command: pip install Numpy. It return the old error Message "Unknown MS Compiler version 1900"

I'm tired. I spend three days to solve this issue but without success.
plz help
msg255386 - (view) Author: Ateik Al-Zehla (Ateik Al-Zehla) Date: 2015-11-25 20:35
forget to tell you that even i deleted the cache, but nothing happened. it use the old code.
msg256890 - (view) Author: Tod Haren (Tod Haren) Date: 2015-12-23 00:50
In addition to patching cygwincompiler.py I also had to patch numpy\distutils\misc_util.py and numpy\distutils\mingw32ccompiler.py to handle the new dll name.

A pull request has been submitted for the numpy patches. https://github.com/numpy/numpy/pull/6875
msg258437 - (view) Author: Marcelo Duarte (marcelotduarte) Date: 2016-01-17 01:02
I hava a problem with others packages, like cchardet and aiohttp.
Aplying the patch changed the error message, then I generate a lib for vcruntime140, and finally, it is installed:

#go to python installation dir
cd M:\Applications\Python35-32
pexports vcruntime140.dll >libs\vcruntime140.def
dlltool -dllname vcruntime140.dll --def libs\vcruntime140.def --output-lib libs\libvcruntime140.a
msg262153 - (view) Author: Jonathan Hanba (hanbaj) Date: 2016-03-21 23:44
I just ran across this bug in Python 3.5.1 while trying to build pycrypto using MinGW. I patched the cygwincompiler.py with the attached patch.diff file, and that got me part of the way there.

With the additions made by patch.diff, the MinGW linker then looked for vcruntime140.dll but it could not find it.

With the Python 3.5.1 installation, vcruntime140.dll is located in ./Python35-32 directory, but it is not included in the library directories being passed into MinGW.

To fix this, I had to edit ./Lib/distutils/command/build_ext.py and add to line 141:

    self.library_dirs.append(os.path.join(sys.exec_prefix))

This adds the root of the Python35-32 directory to the library paths used by MinGW.
msg262199 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-03-22 16:44
Please test your extensions thoroughly when building with MinGW, especially if you're planning on distributing wheels on PyPI.

CPython assumes an ABI compatible with what MSVC would have built, and mixing ABIs will lead to crashes or data corruption. (I'm not just trying to be scary here, this is basically guaranteed to occur when you mix C Runtime libraries.)

Currently the only fully compatible MinGW I'm aware of (mingwpy - https://bitbucket.org/carlkl/mingw-w64-for-python) is still in development, though it appears to be ready for numpy and scipy, which is awesome. But just because "compiler=mingw32" appears to work, it doesn't make it inherently a good idea.

(As an aside, you can get the right version of MSVC for Python 3.5 and later from https://www.microsoft.com/en-us/download/details.aspx?id=49983 - you'll need to build inside the SDK's command line and set DISTUTILS_USE_SDK=1, but otherwise it is the right tools. We've already suggested that they should install in a way that setuptools can automatically detect and use them.)
msg279974 - (view) Author: Sam Miller (Sam Miller) Date: 2016-11-03 08:21
Hi disutils. I got this bug when trying to pip install pomegranate to python 3.5. There is now a m2w64-toolchain (https://github.com/ContinuumIO/anaconda-issues/issues/561)that allows installing the notoriously windows-challenged theano, so I thought this error could be resolved with a new class m2w64Compiler(CygwinCCompiler) or maybe just updating the old Mingw32CCompiler(CygwinCCompiler) class.
msg279997 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-11-03 15:46
That sounds like a great feature for setuptools.

Core distutils is highly focused on what is needed for the core product, and we are very much trying to avoid bloating it, whereas setuptools is free to add extensions wherever necessary and make them available on earlier versions of Python.

The setuptools issue tracker is at https://github.com/pypa/setuptools
msg338959 - (view) Author: Cheryl Sabella (cheryl.sabella) * (Python committer) Date: 2019-03-27 13:26
Should this issue be closed as third-party or do we want to leave it open as reference?
msg341652 - (view) Author: anthony shaw (anthonypjshaw) * (Python triager) Date: 2019-05-06 22:19
Closing as 3rd party feature for setuptools
History
Date User Action Args
2019-05-06 22:19:58anthonypjshawsetstatus: open -> closed

nosy: + anthonypjshaw
messages: + msg341652

resolution: third party
stage: resolved
2019-03-27 13:26:23cheryl.sabellasetnosy: + cheryl.sabella
messages: + msg338959
2016-11-03 15:46:58steve.dowersetmessages: + msg279997
2016-11-03 08:21:43Sam Millersetnosy: + Sam Miller
messages: + msg279974
2016-03-22 16:44:18steve.dowersetmessages: + msg262199
2016-03-21 23:44:02hanbajsetnosy: + hanbaj
messages: + msg262153
2016-01-17 01:02:57marcelotduartesetnosy: + marcelotduarte
messages: + msg258437
2015-12-23 00:50:30Tod Harensetnosy: + Tod Haren
messages: + msg256890
2015-11-25 20:35:33Ateik Al-Zehlasetmessages: + msg255386
2015-11-25 20:31:34Ateik Al-Zehlasetmessages: + msg255384
2015-11-22 22:17:55Matt.Hickfordsetmessages: + msg255113
2015-11-15 12:30:29Ateik Al-Zehlasetnosy: + Ateik Al-Zehla
messages: + msg254687
2015-09-30 21:57:22steve.dowersetmessages: + msg251973
2015-09-30 21:15:44Matt.Hickfordsetmessages: + msg251971
2015-09-28 10:35:05Matt.Hickfordsetfiles: + patch.diff
keywords: + patch
messages: + msg251758
2015-09-27 23:29:22zach.waresetnosy: + zach.ware, paul.moore, tim.golden, steve.dower
type: crash -> behavior
components: + Windows
2015-09-27 22:17:44Matt.Hickfordcreate