Closed grubles closed 2 years ago
@grubles
Can you confirm the libsecp256k1 patch here: https://pastebin.com/yDGxA1wK fixes this? If so I will submit to secp upstream.
Looks like secp256k1-zkp with that patch builds and passes gmake check
.
openbsd71$ gmake check
gmake check-am
gmake[1]: Entering directory '/home/user/secp256k1-zkp'
gmake check-TESTS
gmake[2]: Entering directory '/home/user/secp256k1-zkp'
gmake[3]: Entering directory '/home/user/secp256k1-zkp'
PASS: tests
PASS: exhaustive_tests
============================================================================
Testsuite summary for libsecp256k1 0.1.0-pre
============================================================================
# TOTAL: 2
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
gmake[3]: Leaving directory '/home/user/secp256k1-zkp'
gmake[2]: Leaving directory '/home/user/secp256k1-zkp'
gmake[1]: Leaving directory '/home/user/secp256k1-zkp'
@grubles does it fail just building secp without that patch? That would be very strange.
Building secp256k1-zkp master (without the patch) succeeds.
@jgriffiths Is there a specific commit libwally uses? I could try building that too.
@jgriffiths Is there a specific commit libwally uses? I could try building that too.
No need thanks, the problem is with including the secp sources for building, discussed in detail on the linked secp-zkp PR.
If you patch the c-lightning wally with the below does it build?
diff --git a/src/wrap_js/src/combined.c b/src/wrap_js/src/combined.c
index 6a7d90b8..c69595b5 100644
--- a/src/wrap_js/src/combined.c
+++ b/src/wrap_js/src/combined.c
@@ -35,6 +35,7 @@
#undef PACKAGE_VERSION
#undef VERSION
#undef SECP256K1_BUILD
+#undef swap64
#include "src/secp256k1/src/secp256k1.c"
#include "src/secp256k1/src/precomputed_ecmult_gen.c"
#include "src/secp256k1/src/precomputed_ecmult.c"
I get the same build error using that patch.
Hmm, same error when building wally, or wally builds and then the same error happens in libhsm?
if you can get a full verbose log of the failure building wally (make V=1
) and pastebin it somewhere, we might be able to workaround this faster then waiting for secp to merge the more reliable fix.
Ahh ok. Before I was just running gmake
from the CLN repo directory and running into that build error. This time I've tried building from within /external/libwally-core
and it succeeded with the combined.c
patch!
OK, you can do the same in c-ln in contrib/libhsmd_python/setup.py
temporarily to build.
libsecp has just taken the patch to prevent the name clash, so I will update it in wally master shortly and that should fix the builds without needing the #undef
.
@grubles master is updated, please re-open if you still have issues, thanks
Seems libwally-core release_0.8.5 fails to build when building the Core Lightning project.
Arch: amd64 OS: OpenBSD 7.1 CLN: at commit ad3cbed7c28b2d4e9327885f6c3763f8f4acef41