Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PythonModule's add_python_module dynamically linking to libpython #68

Open
breathe opened this issue May 13, 2019 · 1 comment
Open

Comments

@breathe
Copy link

breathe commented May 13, 2019

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 -

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants