Enhance Python Portability

Question

I have a dll written in C ++ that I want to export to Python to run regression and unit testing (just to simplify support and run regression with Python). For this, I want to use Boost.Python to export the main DLL API so that it can be used in Python. My builds are as follows:

• MyLibrary.dll // main C ++ API library
• MyLibrary.pyd // thin DLL project containing only BOOST_PYTHON_MODULE export BOOST_PYTHON_MODULE (depending on MyLibrary.dll)
• ... // other C ++ DLL files that MyLibrary.dll depend on

I had problems connecting MyLibrary.pyd, but after you sorted out the issues a bit (for example, here ), I realized that I needed to rebuild boost by pointing b2.exe to my specific version of Python. After that, I was able to import and run my library from python (only on my machine ).

Technical data: I build libraries with boost 1.51, Python 3.23 on Windows 7 x64 and MSVC-10.0 (my own projects are built from VS2010). The option that I use to communicate with boost is shared libraries, a 64-address model, release accordingly with my own builds.

The problem is that when I try to import a library (built on my machine) on another machine, python complains:

 ImportError: DLL load failed: The specified procedure could not be found. 

In the line import MyLibrary

Which raises the following questions:

• I created MyLibrary.pyd on my python-portable machine? Sense, will it work with other versions of Python besides 3.23 (the version that I used to build boost.python with my machine)?
• Does MyLibrary.pyd user need to rebuild boost with his own python version in order to be able to import it successfully?
• So far, we have used the preinstalled installation accelerator for windows supplied by BoostPro. What version of Python is related to the assembly, and can I save my users a headache when creating boost myself, if we just decide to work with the "correct" version of Python throughout the team (version related to BoostPro)?

Answer 1

Take a look at PEP 384 at http://docs.python.org/3.2/whatsnew/3.2.html .

http://www.boost.org/doc/libs/1_52_0/libs/python/doc/news.html shows that there has not been any real progress lately, so I doubt that Boost.Python supports or at least least tested Defined by Py_LIMITED_API.

According to my experience with Python 2.x compatibility using both Boost.Python and PyCXX (I haven't worked with the 3.x line yet):

• No, it will not. Only changes to the micro version remain portable ABI.
• Not really. The user of the MyLibrary.pyd binary file you provided will not be able to download it using a different version of major / minor python. The configuration of the Boost assembly that it has does not matter. You need Boost.Python to build with every small version of Python you want to support. This includes separate builds for 32-bit and 64-bit Python installations.

My advice is to try creating Boost from the source using Py_LIMITED_API. I cannot guarantee that it will succeed, but it is worth a try.

If this fails, ask your teammates to use the same version of Python as you and, of course, 64-bit Windows (since .pyd is a 64-bit version). Or it’s even better to configure a CI machine that will build your python module in each configuration you require so that your clients can select the correct binary. Let your teammates build and use their own versions of MyLibrary.pyd only for their local use.