Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
configure.ac: support --with-system-secp256k1
Libwally-core, in its stock configuration, compiles and statically links against a private copy of libsecp256k1_zkp. However, Gentoo unbundles libsecp256k1_zkp and instead links libwally-core against a system-wide shared libsecp256k1_zkp with headers in /usr/include/secp256k1_zkp and a libsecp256k1_zkp.pc that specifies the relevant CFLAGS and LIBS. Implement a --with-system-secp256k1 configure option to allow compiling and linking against a system-installed libsecp256k1. Pass the user- specified package name (or 'libsecp256k1' or 'libsecp256k1_zkp' by default, depending on --enable-standard-secp) to PKG_CHECK_MODULES to find the CFLAGS and LIBS of a system-installed libsecp256k1. Call AC_CHECK_FUNCS to assert that the required modules are present in the system-installed libsecp256k1. If the user does not specify --with-system-secp256k1 (or specifies --without-system-secp256k1), then the pre-existing behavior is preserved: namely, the build will use the bundled copy of libsecp256k1_zkp. setup.py is tweaked to detect if the libwally-core library has already been built and, in that case, elide rebuilding it. This supports a use case of linking libwallycore.so against a system-installed libsecp256k1 and then linking the Python extension against that libwallycore.so. In such a scenario, the Python native extension library contains no code from libwally-core or libsecp256k1 but instead simply specifies a dynamic link with libwallycore.so.1, and libwallycore.so.1 contains no code from libsecp256k1 but instead simply specifies a dynamic link with libsecp256k1_zkp.so.0. This is the "full dynamic link" holy grail. Note that the default case is nearly the opposite: all libsecp256k1 and libwally-core code is embedded into the Python native extension library.
- Loading branch information