Windows build in MSVC 2015

[WojciechMula]

Nishant Sharma has reported that following change is required in windows.h

typedef __int32 int32_t
typedef unsinged __int32 uint32_t

in order to build with the latest MSVC. I'll include it in the next release.

[pombredanne]

Note that Python 2 and 3 have some constraints about which version of MSVC you can use: you should be using the same version that was used to build the Python interpreter itself in general (though there are some relaxing of this rule with introduction of some somewhat stable ABI in Py 3).

[WojciechMula]

But we should provide support for all version, in case if somebody is building the interpreter using another MSVC version. In this case it's a matter of one #ifdef, I hope :)

[pombredanne]

You wrote:

In this case it's a matter of one #ifdef, I hope :)

not entirely: you CANNOT build Python extensions on Windows with another MSVC compiler than the one used to compiled the Python interpreter in general. There are very few exceptions and this is fraught with perils: I was able at time to get a few using MinGW but in general you are likely to experience any kind of issues.

This is why MSFT kept and offers a trimmed down version of the MSVC 2008 compiler for Python 2.7.

[WojciechMula]

Thanks for making this clear.

However, Nishant works for Microsoft and was successfully compiled the module with MSVC 2015. So, maybe they're doing something with python itself? I will ask.

[pombredanne]

If MSFT can do it then indeed this is possible! Could it be they recompiled Python 2.7 with MSVC 2015? But on Python 3, as fas as I know the game is different as there is some ABI now.

[pombredanne]

@WojciechMula It would be great if Nishant could chime in here.

[pombredanne]

And FWIW, unless you rebuild Python, MSVC 2015 may make sense only for Python3.5

[nishantsharma]

I built it for Python 64-bit 3.5 interpreter. It came as part of Anaconda3 from Continuum. The built module has been working fine.

[pombredanne]

@nishantsharma that's great. And yes I would have expected the Python 3.5 and MSVC 2015 combo to work just fine.

[pombredanne]

@WojciechMula you did already made the changes you mentioned above #37 (comment) , right?

[WojciechMula]

@pombredanne not yet

[jableckim]

By the way, you might want to use the following in windows.h:

typedef unsigned __int8 uint8_t;
typedef unsigned __int16 uint16_t;
typedef unsigned __int32 uint32_t;

I just don't like the non-explicit specification of the number of bits.

[WojciechMula]

@jableckim Thanks, but is it safe? I mean, are these __intXX types always provided by MSVC?

[jableckim]

Well, Microsoft is known for breaking things now and then but ... this appears to be standard. As of Tuesday, Nov 29, 2016 this page seems to say that MS uses these in VS2015 as a documented way to be a bit more portable across platforms. https://msdn.microsoft.com/en-us/library/29dh1w7z.aspx Hope that helps. MJ

…

On Tue, Nov 29, 2016 at 10:55 AM, Wojciech Muła ***@***.***> wrote: @jableckim <https://github.com/jableckim> Thanks, but is it safe? I mean, are these __intXX types always provided by MSVC? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMKa34axNlIY87qLb_BNTyrIy5oaDceVks5rDHUUgaJpZM4JYYf4> .

[pombredanne]

@jableckim the thing is that not any MSVC compiler can be used with Python in general. Usually the MSVC compiler used to compile Python itself should be used at least on Python 2. I think things have been relaxed a bit the latest Python 3 with the emergence of a proper ABI... but this is just OTH.

[WojciechMula]

I'm closing this issue, as it's a duplicate of #51 (where a portable solution was proposed).