Python linkage enhancements #419
Conversation
libwallycore.la is linked into the Python native extension library. Previously this wasn't really being done at all; rather, all of the libwally-core code was being recompiled into some "combined" objects that would then be linked into the Python extension. This was a needless duplication of work since the compiled objects already exist in libwallycore.a and libsecp256k1.a. Simply link those libraries into the extension. Since Windows does not use libtool, continue to compile the "combined" objects on Windows until a cleaner solution can be implemented.
Iff the environment contains WALLY_ABI_PY_WHEEL_USE_DSO=1, then: * setup.py will configure and build libwally-core as a shared library; * the Python native extension library will not contain any libwally-core or libsecp256k1 code; and * the dynamic linker will need to find and load libwallycore.so.1 whenever the Python native extension is loaded.
@jgriffiths: This is the command line that Gentoo's
In either case, after building the wheel, the machinery runs this command to install it into a staging location: I'm not sure if any of that helps you at all. (I rather doubt it.) |
|
@jgriffiths: Did this slip through the cracks, or have you decided not to support this after all? |
|
@whitslack yes it did. The python build machinery has been updated somewhat, so this will need re-working. Please submit under a new PR if you would. |
On systems supporting Libtool (i.e., anything but Windows), skip compiling the "amalgamated" sources for the Python module and simply link in the just-built
libwallycore.aandlibsecp256k1.a.setup.py: support optionally building and linking to libwally-core as a dynamic shared object ifWALLY_ABI_PY_WHEEL_USE_DSO=1is set. Ignored on Windows, wheresetup.pydoes not build libwally-core.