Choosing a Boost.Python Library Binary

The Dynamic Binary
The Static Binary

If—instead of letting Boost.Build construct and link with the right libraries automatically—you choose to use a pre-built Boost.Python library, you'll need to think about which one to link with. The Boost.Python binary comes in both static and dynamic flavors. Take care to choose the right flavor for your application. ^[3]

The Dynamic Binary

The dynamic library is the safest and most-versatile choice:

A single copy of the library code is used by all extension modules built with a given toolset. ^[4]
The library contains a type conversion registry. Because one registry is shared among all extension modules, instances of a class exposed to Python in one dynamically-loaded extension module can be passed to functions exposed in another such module.

The Static Binary

It might be appropriate to use the static Boost.Python library in any of the following cases:

You are extending python and the types exposed in your dynamically-loaded extension module don't need to be used by any other Boost.Python extension modules, and you don't care if the core library code is duplicated among them.
You are embedding python in your application and either:
- You are targeting a Unix variant OS other than MacOS or AIX, where the dynamically-loaded extension modules can “see” the Boost.Python library symbols that are part of the executable.
- Or, you have statically linked some Boost.Python extension modules into your application and you don't care if any dynamically-loaded Boost.Python extension modules are able to use the types exposed by your statically-linked extension modules (and vice-versa).

^[3] Information about how to identify the static and dynamic builds of Boost.Python on Windows / Unix variants

^[4] Because of the way most *nix platforms share symbols among dynamically-loaded objects, I'm not certain that extension modules built with different compiler toolsets will always use different copies of the Boost.Python library when loaded into the same Python instance. Not using different libraries could be a good thing if the compilers have compatible ABIs, because extension modules built with the two libraries would be interoperable. Otherwise, it could spell disaster, since an extension module and the Boost.Python library would have different ideas of such things as class layout. I would appreciate someone doing the experiment to find out what happens.