I'm looking for advice on compiling C++11

[MatthiasKauer]

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

[MatthiasKauer]

I have investigated this a bit further today.
The C++11 code I'm testing is here: https://github.com/MatthiasKauer/python-cpp-miniextension/blob/ionelmc-appveyor/mylib/c%2B%2B11swig_factorial/factorial.h
I'm wrapping this with swig and try to build it locally (Linux) and on AppVeyor, both with your and with ionelmc's scripts, mentioned in #29
On Linux, using -std=c++11 is no issue. On Appveyor, the result is still that your scripts build Python 3.3 and 3.4, but not 2.7. ionelmc's scripts only succeed for Python 3.5.

Consider this build, using ogriesel scripts https://ci.appveyor.com/project/MatthiasKauer/python-cpp-miniextension/build/1.0.25
and this build using ionelmc scripts https://ci.appveyor.com/project/MatthiasKauer/python-cpp-miniextension/build/ionelmc-appveyor-21

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

[anthrotype]

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.

[ogrisel]

@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
https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/

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.

[ogrisel]

Closing this as I don't think we can do much as part of the python-appveyor-demo project it-self.

[MatthiasKauer]

Thanks for the input!
Especially for the heads-up that MingW will need a runtime on the user to run libraries even if I built them in the wheel format. Did I understand that correctly?

[anthrotype]

Not if you statically link libgcc and libstdc++.

See:
https://github.com/google/brotli/blob/master/setup.py

[ogrisel]

I think there is more than statically linking the C and C++ runtimes: they are also long long precision incompatibilities and C++ exception management problems with extensions built with MSVC although I am not very familiar with the details.

@carlkl knows the details better than I do.

[carlkl]

You may simply try to install a prerelease of mingwpy (the successor of the thing that was called mingw-w64-for-python) the following way:

Install with pip:
pip install -i https://pypi.anaconda.org/carlkl/simple mingwpy

or with conda: (thanks to omnia-md)
conda install -c https://conda.anaconda.org/omnia mingwpy

You may need to configure %USERPROFILE%\pydistutils.cfg to use the toolchain if you have an MSVC compiler installed.

If the Scripts folder of python is in your PATH you are done, otherwise you have to do this or add the bin folder of the toolchain into your PATH.

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.

[MatthiasKauer]

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
I'm particularly interested to find out how it is different from

conda install mingw

Is it just about 32bit/64bit?
Or have you adjusted static linking and the gcc version as well?

[carlkl]

conda install mingw installes the mingw conda package from continuum.io. Using MSVC in favour of this mingw package is now proposed by continuum.io:
https://groups.google.com/a/continuum.io/forum/#!searchin/anaconda/mingw$20in$20Anaconda$202.2.0/anaconda/XLcpwFDjwmg/9qXHSBcaZqMJ.

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.