Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Panda3D wheel for linux contain static version of the libpython library #839
The manylinux wheel of Panda3D contains the static version of libpython, e.g. deploy_libs/libpython3.7m.a in panda3d-1.10.5+opt-cp37-cp37m-manylinux1_x86_64.whl, where macosx version contains deploy_libs/libpython3.7.dylib and win_amd64 contains deploy_libs/python37.dll
This causes problem with CEFPython whose library on Linux, cefpython3.cefpython_py37.so, refers to libpython3.7m.so.1.0
I detected this while writing a CI workflow for my app that now test the generation of the app binaries and test a headless version of it to check that all the dependencies are working correctly.
This went under the radar on my hosts as they are all dev machines with Python installed on them and so the missing library was found in the system.
This is a CEFPython build issue. Python does not allow extension modules to link with libpython.so. Instead, the symbols are made available dynamically by the interpreter. This is to ensure that extension modules can be loaded by other interpreters than the one it was linked against, and even static builds of Python (which are common).
There is no shared library for Python available in the manylinux container since the copy of Python was built statically there. This is in accordance with the manylinux specification.
I suppose that it is a mistake that we ship the .a file at all, since deploy-ng has no use for it.
You should file this as an issue upstream; CEFPython needs to use a special linker flag to enable creating the extension module without linking to libpython.
Ok, and now I understand why cefpython3.cefpython_py37.so on macOS does reference lib libpython3.7.dylib.
I will fill an issue for CEFPython, do you have a reference in the Python documentation that I could use ?
EDIT: Found this information https://www.python.org/dev/peps/pep-0513/#libpythonx-y-so-1
I think on macOS the practice is also not to link against libpython3.7.dylib. In fact, doing so makes it impossible to use a different distribution of Python, such as Homebrew.
What's a little odd is that the manylinux1 container doesn't even contain libpython3.7.so, so they must have had to go out of their way to modify it. Or are they not using the manylinux1 container, yet calling it manylinux1? You might want to use auditwheel to check that these are in fact valid manylinux1 wheels to begin with; if not, you can report the auditwheel results upstream.
Here is the documentation describing that manylinux1 wheels may not link to libpython3.7.so.1:
This page shows the linker flags you should use to avoid the need to link to libpython: (I remember it's in more recent docs too, I just can't find it right now)
I wonder if you can work around this bug by shipping a dummy libpython3.7m.so.1.0 containing no symbols.