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

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>
> _______________________________________
>

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':

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).

how to apply patch file : patch.diff ? plz help

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>
> _______________________________________
>

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

forget to tell you that even i deleted the cache, but nothing happened. it use the old code.

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

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

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.

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.)

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.

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

Should this issue be closed as third-party or do we want to leave it open as reference?

Closing as 3rd party feature for setuptools