-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I'm looking for advice on compiling C++11 #34
Comments
I have investigated this a bit further today. Consider this build, using ogriesel scripts https://ci.appveyor.com/project/MatthiasKauer/python-cpp-miniextension/build/1.0.25 Looking at the logs: ogriesel builds Python 3.4 w/ WinSDK 7.1 for 64, local MSVC (10.0) for 32 bit while ionelmc fails to find WinSDK 7.1 for 64 bit (probably my fault) and MSVC 10.0 but fails (which I don't understand b/c it literally tries to build w/ the same command but then fails w/ the vector {1, 2} initialization). This may be useful to know when considering switching to the Python script in #29 |
Python 2.7 on Windows is built using Microsoft Visual Studio 2008, which does not support C++11 features. You may try monkey-patching distutils in your setup.py to force it use Visual Studio 2010 instead (i.e. the one Python 3 is compiled with), but many discourage linking extension modules against MSVC runtime versions different from the main interpreter's. It may or may not work in your case, but it's worth trying. Another solution is to use the MinGW gcc compiler to build your extension module. |
@anthrotype's answer seems correct to me. Using MinGW to build Python extensions will require your users to have it installed on there platform to be able to load your extensions though. Unless you use a static toolchain such as: https://anaconda.org/carlkl/mingwpy Unfortunately this toolchain is still experimental and not very well documented yet. Note that using MingGW for Python 3.5 is not yet possible though as far as I know. |
Closing this as I don't think we can do much as part of the |
Thanks for the input! |
Not if you statically link libgcc and libstdc++. See: |
I think there is more than statically linking the C and C++ runtimes: they are also @carlkl knows the details better than I do. |
You may simply try to install a prerelease of Install with pip: or with conda: (thanks to omnia-md) You may need to configure If the CPython-3.5 is not supported at the moment. And yes, all binaries are statically linked and don't need additional gcc runtime libraries. The toolchain is configured using standard win32 threads as default (supporting pthreads with the help of winpthreads library). This configuration is the fastest but does not support new C++11 thread features. |
Thanks all for the additional insight, all of you! @carlkl is there a web presence for mingwpy? I only find this bitbucket repo: https://bitbucket.org/carlkl/mingw-w64-for-python
Is it just about 32bit/64bit? |
mingwpy is a newer independently developed package containing an adapted mingw-w64 based gcc-toolchain (gcc-4.9.2). This package is addressing many problems users experienced with the combination of mingw-w64 compiled binary extensions used from within standard MSVC based Windows Python installations. There is a preliminary somewhat outdated documention on the bitbucket site you mentioned. A newer website with documenation is in preperation. Any feedback on the usage of mingwpy is welcome. |
Hi,
thank you very much for starting this project. I have found it very useful already.
I'm wondering if anyone can offer guidance on compiling C++11 code.
My example code (which hinges on and <stdint.h>) compiles out of the box with your script for Python 3.3 and above on any architecture. These are the versions where WinSDK 7.1 is used if I understand correctly.
In case of Python 2.7, I have managed to make it build for x64 by adjusting your script and forcing WinSDK 7.1 there too. For the 32 bit version I couldn't make this work yet, however. The most likely reason is that I didn't set 32 bit for the compiler version correctly.
Even if I could fix this though, I'm wondering whether there is a reason you're avoiding the newer SDK on the old Python versions or whether it's just because the usual compilers worked for you in that case. Can you comment on that?
Kind regards,
Matthias
The text was updated successfully, but these errors were encountered: