Python 3.5 wheels

[zommuter]

See https://mingwpy.github.io/issues.html#choice-of-msvc-runtime, but there's no ticket here yet

[carlkl]

VS 2015 compatibility has technical and legal issues compared to the VS 2008 or VS 2010.

The biggest showstopper are the missing file stream functions. These functions are not part of the MS runtime DLLs anymore. You have to use the MS header files (as dome by Visual studio itself) or a special static importfile delivered as part of the VS 2015 distribution. Obviously you can't deliver this import file as part of a mingw-w64 based toolchain due to legal reasons.

[zommuter]

That's very unfortunate... So one would have to download e.g. the VS 2015 Enterprise ISO of several GB just to get a few KB worth of files, but with those it might be fixed to work?

Maybe there is a way to only depend on the Microsoft Visual C++ 2015 Redistributable?

[techtonik]

I guess that's the model that Microsoft wants to enforce. There is no cure from this other than improve UX on Linux.

[anthrotype]

So one would have to download e.g. the VS 2015 Enterprise ISO of several GB just to get a few KB worth of files...

What about the "Visual C++ Build Tools"?
http://landinghub.visualstudio.com/visual-cpp-build-tools

[stonebig]

visual-cpp-build-tools 2015 is 4go, over-internet installer, admin rights software. It's unfortunate for Windows end-users that situation will be more comfortable under Python 2.7 and 3.4 for next 3 years.

[carlkl]

see conda-forge/openblas-feedstock#2 (comment) for a different discussion thread about VS 2015 / mingw-w64 compatibility

[stonebig]

If you've eliminated all other possibilities whatever remains must be the truth

[stonebig]

any news on Legal front ? any alternative in sight (besides installing Python 3.4 next to 3.5) ?

[rgommers]

any news on Legal front ?

not that I know of

any alternative in sight (besides installing Python 3.4 next to 3.5) ?

hopefully Flang sometime soon

[coldfix]

Would it be possible to provide a preliminary solution that does not ship ucrt.lib with mingwpy - instead instructing the user to separately download the windows SDK and put the file in the correct location?

While this is obviously not a long-term solution, it would already be extremely useful for developers to provide prebuilt wheels for their packages (where MSVC is not an option).

BTW: from what you've been writing in mingwpy.github.io/issues and especially in the conclusions of mingwpy.github.io/ucrt, it seems to me that you have everything to create your own .lib file (good work!!). Is there anything else blocking the road, or maybe some work needed to be done where a relative newbie like me could help?

Best, Thomas

[carlkl]

Hi Thomas,

linking against ucrt.lib is technically not the correct approach. You have to link directly against all 14 api-ms-win-crt-* import libraries instead. I was asked from another interested party to find a feasible solution recently. Working this out in not as easy as it seems. The best approach for now is to create a conflated import library against all needed api-ms.dlls as well as vcruntime140.dll for some symbols and msvcrt.dll as well for all fileio functions, that are not available right now. So this solution is only partially UCRT compatible.

I'm always open for technical help and/or testing.

[coldfix]

Oh.. from what I understood from mingwpy.github.io/ucrt and stevedower.id.au/blog/building-for-python-3-5, I thought that ucrt.lib ships the list of symbols versus all the ap-ms.dlls and linking with this .lib file would be the technically correct solution by official definition - the issue being just that mingwpy is not allowed to ship the official .lib file for legal reasons. So, I misunderstood?

[carlkl]

You are correct, linking against ucrt.lib uses correctly the so called API sets. However, using a conflated mingw-w64 import library as desribed above should to it as well. The advantage is, that it can be deployed in contrast to the ucrt.lib from MS.

[carlkl]

You are correct, linking against ucrt.lib uses correctly the so called API sets. However, using a conflated mingw-w64 import library as desribed above should to it as well. The advantage is, that it can be deployed in contrast to the ucrt.lib from MS.