PythonModule's add_python_module dynamically linking to libpython

[breathe]

Hi -- apologies for my lack of cmake-fu -- hopefully I can describe the issue as I understand it accurately enough ...

I'm trying to build the pylada-light library against recent anaconda python releases (python 3.6, 3.7 in particular). pylada-light uses the GreatCMakeCookOff and invokes the add_python_module to build cython extensions. When building against anaconda python 3.4, things work but when building against versions 3.5 or greater -- the build completes but I get a segfault when I try to import any of the extension modules distributed with pylada (observed on macOS mojave and travis-ci flavor ubuntu linux).

From what I can understand this results because pylada-light's build process (via GreatCMakeCookOff) produces extension modules that are dynamically linked to libpython. This creates a symbol conflict as the newer anaconda python distribution statically link libpython when building the interpreter. I believe there's some discussion of this issue here -- https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/057P4uNWyCU

From what I can understand this is the line in GreatCMakeCookOff that causes the dynamic linkage to happen -

GreatCMakeCookOff/scripts/PythonModule.cmake

Line 138 in 2539e65

target_link_libraries(${module_target} ${PYTHON_LIBRARIES})

I was able to hack that line in a fork and produce a working build -- https://github.com/breathe/GreatCMakeCookOff/blob/f57d9948f751ccec9023f41536fc269f464d08e5/scripts/PythonModule.cmake#L139

There's also this thread, in which it seems that features are being added to cmake to improve on this use scenario --
https://gitlab.kitware.com/cmake/cmake/issues/18100. I don't exactly understand what's going on in that thread but seems people are tackling the same issue.

I'm wondering if anyone has a suggestion for correct way to fix this issue ...? Is there a change needed in GreatCMakeCookOff or a good way to workaround from consuming project ...?

Many thanks!

[mdavezac]

For reference, the best option is probably to use scikit-build, with FindPython3's Python3_USE_STATIC_LIB. I.e. the best option today is probably not to use the cookoff.