You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Embedding SWIG Python code into libwallycore.so ties the library to a
specific version of Python, thereby precluding concurrent installation
of the wallycore Python module for multiple implementations of Python
on the same system if the Python modules are linked with a system-wide
libwallycore.so. On Gentoo at least, linking libwallycore.so with
libpython3.14.so and then attempting to use the wallycore Python module
from Python 3.11, 3.12, or 3.13 causes an immediate segfault.
Rather than injecting Python-specific glue into libwallycore.so, we can
and should keep it contained within the Python native extension library
that we build for each Python implementation. The Python wheel actually
already compiles swig_python_wrap.c and links it into the native
extension library, so linking it into libwallycore.so as well is
redundant and harmful.
* Remove libswig_python.la from libwallycore_la_LIBADD, and expunge its
existence from Makefile.am entirely since it's now unused.
* The Python wheel build for each Python implementation compiles
swig_python_wrap.c against the headers for that particular Python
implementation, ensuring that the resulting native extension library
matches the ABI of the Python implementation for which it is
installed. This may be a different Python implementation than the one
found by Autoconf, the only relevance of which now is in finding the
interpreter with which to run the tests.
* Since we no longer link libwallycore.so with libpython*.so, there
should no longer be any manylinux compatibility issues, so drop the
--enable-python-manylinux Autoconf option and the PYTHON_MANYLINUX
Automake conditional. This also means that the test programs no longer
need to link with $(PYTHON_LIBS) since libwallycore.la now never has
any dependence on Python (implicit or explicit).
* Note that the Python native extension libraries do not explicitly link
with libpython*.so either. This is correct, as the dynamic linker
resolves their undefined Py* symbols when it loads them into the
Python interpreter.
* manylinux intentionally omits libpython*.so libraries from its build
containers to discourage/prevent wheels' native extension libraries
from linking against the Python DSO. We don't do that (anymore), but
the AX_PYTHON_DEVEL Autoconf macro expects to be able to find it and
fails its final sanity check if it can't. Thankfully, more recent
versions of the macro support an 'optional' flag that allows configure
to proceed even if the check fails. So now we set that flag and just
check that we have a value in $PYTHON_CPPFLAGS, which is all the
SWIG_PYTHON macro cares about in the first place.
After applying these changes, the Gentoo ebuild for libwally-core 1.5.0
now successfully runs the SWIG Python tests on all currently supported
versions of Python (3.11 through 3.14), all using the same
libwallycore.so.6.
0 commit comments