test CI #423
Merged
test CI #423
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jgriffiths
force-pushed
the
abi_merge_tmp
branch
from
b9434ac
to
b13e17f
Compare
Third party libraries that make use of wally can use these calls to avoid potential mismatches by end user applications that override the default allocator.
Based on a patch by Marko Bencun <marko@shiftcrypto.ch>.
Original commit description/rationale:
When configuring libwally core with these flags:
./configure --enable-static --disable-shared
and compiling using `make`, libtool outputs this message:
copying selected object files to avoid basename conflicts...
It copies the base64 and hex object files as they have the same
basename as the files built from `src/ccan/ccan/base64/base64.c`
`ccan/ccan/str/hex/hex.c`.
By using `make V=1` one can see that it is trying to copy it using
`ln` (a hardlink). This does not work properly inside a Docker
container on macOS, where the hard link is created but cannot be used
immediately ("file not found" in the next step where the object files
are used in linking). We tested this on two macOS machines, and it
only consistently did not work on one of them. We could not figure out
the root cause for the error. Giving the files unique names avoids the
copying/hardlinking and avoids the error.
version-info is what determines the dotted triplet of numbers trailing the shared library filename. Meticulous maintenance of version-info allows multiple ABI versions of the library to be installed on a system concurrently and also makes obvious when library clients need to be recompiled for a newer ABI (and when no recompilation is necessary). See: https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
Altering ac_configure_args to configure libsecp256k1 with options differing from those of libwally-core causes issues if the wally Makefile is out of date and needs to call autoreconf etc to regenerate itself. The secp arguments are passed back to the top level configure which changes and possibly breaks the original configuration. Instead, import and use AX_SUBDIRS_CONFIGURE from the autoconf-archive which supports sub-confiration with bespoke arguments. Because autoreconf does not recurse into subdirectories named by AX_SUBDIRS_CONFIGURE, we lose the automagic Autotools (re)generation in src/secp256k1, so add an explicit call to src/secp256k1/autogen.sh in tools/autogen.sh.
(Modified from the original submission). 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), the build will use the bundled copy of libsecp256k1_zkp as before. Remove the existing libtool hack: When building as a static library, the user will need to link libsecp256k1.a in addition to libwallycore.a.
jgriffiths
force-pushed
the
abi_merge_tmp
branch
from
b13e17f
to
15bff1e
Compare
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Temporary PR to test CI since the one on #414 isn't running for some reason