Boost :: Python no encuentra clase de C ++ en OSX - python, c ++, macos, boost, boost-python

Estoy portando una aplicación de Linux a OS X y la integración de Boost :: Python está fallando en el tiempo de ejecución.

Estoy exponiendo mis clases de C ++ así:

using namespace scarlet;

BOOST_PYTHON_MODULE(libscarlet) {
using namespace boost::python;

class_<VideoEngine, boost::noncopyable>("VideoEngine", no_init)
.def("play", &VideoEngine::play)
.def("pause", &VideoEngine::pause)
.def("isPaused", &VideoEngine::isPaused)
[...]
;
}

Estoy importando la biblioteca así:

try {
boost::python::import("libscarlet");
} catch (boost::python::error_already_set & e) {
PyErr_Print();
}

Luego inyecto una instancia en el espacio de nombres global de Python de la siguiente manera:

void VideoEngine::init() {
[...]
try {
auto main_module = boost::python::import("__main__");
auto main_namespace = main_module.attr("__dict__");
main_namespace["engine"] = boost::python::object(boost::python::ptr(this));
} catch (boost::python::error_already_set & e) {
PyErr_Print();
}
[...]
}

Funciona muy bien en Linux, pero en OS X se lanza una excepción y PyErr_Print() devoluciones TypeError: No Python class registered for C++ class scarlet::VideoEngine.

Por lo que puedo decir, el módulo funciona sinproblema cuando se importa a través del intérprete de Python. Es difícil de probar ya que está diseñado para ser inyectado como una instancia preconstruida, pero la clase y las funciones están presentes como se muestra a continuación:

$ python
Python 2.7.5 (default, Mar  9 2014, 22:15:05)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import libscarlet
>>> libscarlet.VideoEngine
<class "libscarlet.VideoEngine">
>>> libscarlet.VideoEngine.play
<unbound method VideoEngine.play>

¿Alguna idea de dónde está la incompatibilidad?

Editar: Estoy empezando a pensar que podría estar relacionado consubprocesos múltiples desde que mi implementación de OS X usa una estructura de subprocesos diferente, aunque todas las llamadas detalladas aquí ocurren en el mismo subproceso. ¿Podría ser la causa de tal problema? Probablemente no sea el problema, ya que no funciona en MS Windows en modo de subproceso único.

Respuestas

He resuelto esto ahora.

Fue causado completamente por la compilación estática de Boost :: Python y una vez que lo compilé como una biblioteca compartida, el problema desapareció por completo en todas las plataformas.

La lección: no compile el impulso de forma estática. Estoy bastante seguro de que hay advertencias contra él y deben ser atendidas.