cabe085bb4 configure: Remove pkgconfig macros again (reintroduced by mismerge) (Tim Ruffing)
Pull request description:
We had removed `PKG_PROG_PKG_CONFIG` in 21b2ebaf74
(#1090). But then then the not rebased (!) merge of 2be6ba0fed
(#1084) brought that macro back at another location, without git
complaining about a conflict.
Fixes#1127.
ACKs for top commit:
fanquake:
ACK cabe085bb4
hebasto:
ACK cabe085bb4
jonasnick:
ACK cabe085bb4
Tree-SHA512: ba497503db3a11e631b15c4fe875e62d892971c2c708d90b2f6be684e85d164043ea97c13af0452831eef41f3cf8230cd8a9eafa332dc5b5ae18e118b87c3828
We had removed `PKG_PROG_PKG_CONFIG` in 21b2ebaf74
(#1090). But then then the not rebased (!) merge of 2be6ba0fed
(#1084) brought that macro back at another location, without git
complaining about a conflict.
Fixes#1127.
17065f48ae tests: Randomize the context with probability 15/16 instead of 1/4 (Tim Ruffing)
Pull request description:
ACKs for top commit:
sipa:
ACK 17065f48ae
jonasnick:
ACK 17065f48ae
Tree-SHA512: 3b7005770007b922a294be610f23da60b0dde74dfd7585d64a2cb04eaa6ec879de8d21a0ade31c1857019a8dd97260fa3aa167ae16fc55027ef280a3e3feaa6d
55f8bc99dc ecmult_gen: Improve comments about projective blinding (Tim Ruffing)
7a86955800 ecmult_gen: Simplify code (no observable change) (Tim Ruffing)
4cc0b1b669 ecmult_gen: Skip RNG when creating blinding if no seed is available (Tim Ruffing)
Pull request description:
Running the RNG is pointless if no seed is available because the key
will be fixed. The computation just wastes time.
Previously, users could avoid this computation at least by asking for
a context without signing capabilities. But since 3b0c218 we always
build an ecmult_gen context, ignoring the context flags. Moreover,
users could never avoid this pointless computation when asking for
the creation of a signing context.
This fixes one item in #1065.
ACKs for top commit:
sipa:
ACK 55f8bc99dc
apoelstra:
ACK 55f8bc99dc
Tree-SHA512: 5ccba56041f94fa8f40a8a56ce505369ff2e0ed20cd7f0bfc3fdfffa5fa7bf826a93602b9b2455a352865a9548ab4928e858c19bb5af7ec221594a3bf25c4f3d
Whenever I read this code, I first think that rescaling ctx->initial is
a dead store because we overwrite it later with gb. But that's wrong.
The rescaling blinds the computation of gb and affects its result.
Running the RNG is pointless if no seed is available because the key
will be fixed. The computation just wastes time.
Previously, users could avoid this computation at least by asking for
a context without signing capabilities. But since 3b0c218 we always
build an ecmult_gen context, ignoring the context flags. Moreover,
users could never avoid this pointless computation when asking for
the creation of a signing context.
40a3473a9d build: Fix #include "..." paths to get rid of further -I arguments (Tim Ruffing)
Pull request description:
This simplifies building without a build system.
This is in line with #925; the paths fixed here were either forgotten
there or only introduced later. This commit also makes the Makefile
stricter so that further "wrong" #include paths will lead to build
errors even in autotools builds.
This belongs to #929.
ACKs for top commit:
hebasto:
ACK 40a3473a9d
Tree-SHA512: 6f4d825ea3cf86b13f294e2ec19fafc29660fa99450e6b579157d7a6e9bdb3404d761edf89c1135fa89b984d6431a527beeb97031dc90f2fae9761528f4d06d1
This simplifies building without a build system.
This is in line with #925; the paths fixed here were either forgotten
there or only introduced later. This commit also makes the Makefile
stricter so that further "wrong" #include paths will lead to build
errors even in autotools builds.
This belongs to #929.
Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
49e2acd927 configure: Improve rationale for WERROR_CFLAGS (Tim Ruffing)
8dc4b03341 ci: Add a C++ job that compiles the public headers without -fpermissive (Tim Ruffing)
51f296a46c ci: Run persistent wineserver to speed up wine (Tim Ruffing)
3fb3269c22 ci: Add 32-bit MinGW64 build (Tim Ruffing)
9efc2e5221 ci: Add MSVC builds (Tim Ruffing)
2be6ba0fed configure: Convince autotools to work with MSVC's archiver lib.exe (Tim Ruffing)
bd81f4140a schnorrsig bench: Suppress a stupid warning in MSVC (Tim Ruffing)
09f3d71c51 configure: Add a few CFLAGS for MSVC (Tim Ruffing)
3b4f3d0d46 build: Reject C++ compilers in the preprocessor (Tim Ruffing)
1cc0941414 configure: Don't abort if the compiler does not define __STDC__ (Tim Ruffing)
cca8cbbac8 configure: Output message when checking for valgrind (Tim Ruffing)
1a6be5745f bench: Make benchmarks compile on MSVC (Tim Ruffing)
Pull request description:
ACKs for top commit:
jonasnick:
ACK 49e2acd927
Tree-SHA512: 986c498fb218231fff3519167d34a92e11dea6a4383788a9723be105c20578cd483c6b06ba5686c6669e3a02cfeebc29b8e5f1428552ebf4ec67fa7a86957548
This commit also raises the TEST_ITERS for wine tasks to the default.
The overhead of wine is negligible, so we can certainly afford the same
number of iterations as for native Linux tests.
This adds MSVC builds built on Linux using wine. This requires some
settings of tools and flags because the autotools support for MSVC is
naturally somewhat limited.
The advantage of this approach is that it is compatible with our
existing CI scripts, so there's no need to write a Windows CI script
(in PowerShell or similar). If we want to test building and running on
Windows native (e.g., as supported by Cirrus CI) we could still do this
in the future.
Another advantage of this approach is that contributors can simply use
the docker image if they need a MSVC installation in a non-Windows
environment.
This commit also improves the Dockerfile by grouping RUN commands
according to Docker docs:
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#run
6f6cab9989 abi: Don't export symbols in static Windows libraries (Cory Fields)
Pull request description:
For context, Bitcoin Core has recently merged [libbitcoin-kernel](https://github.com/bitcoin/bitcoin/pull/24322), a small library that intends to eventually minimally encompass Core's validation engine. This kernel lib includes a static libsecp256k1. Without this change, because libsecp256k1.a ends up with exported symbols, we end up with libsecp256k1 symbols exported by our libbitcoin-kernel library (which causes unrelated problems not worth getting into here).
libtool takes care of building both object versions, and it automatically builds objects for shared libs with -DDLL_EXPORT. We just need to opt-in to its functionality.
I can't imagine this having any negative impact on any current statically-linking applications, if anything they'll just be a tiny bit smaller because they can now strip unused symbols.
ACKs for top commit:
real-or-random:
utACK 6f6cab9989
theuni:
> Not sure what other changes made compilation on CI fail but Concept ACK [6f6cab9](6f6cab9989). This should be entirely harmless.
sipa:
utACK 6f6cab9989
laanwj:
utACK 6f6cab9989
Tree-SHA512: 39f240046639738f7a8c01068e728b2f9ceac2754cc4b0a5fa46c28f6f57a8c4124653b56dfbf5c13106b07c11ac599cc41b508e16862d539ce1af6c3365a205
7efc9835a9 Fix the false positive of `SECP_64BIT_ASM_CHECK` (Sprite)
Pull request description:
I'm trying to compile this project for RISC-V architecture, and I encountered errors:
```
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r15' in 'asm'
28 | __asm__ __volatile__(
| ^
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r14' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r13' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r12' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r11' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r10' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r9' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r8' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%rdx' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%rcx' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%rax' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: output number 0 not directly addressable
src/field_5x52_asm_impl.h: In function 'secp256k1_fe_sqr':
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r15' in 'asm'
298 | __asm__ __volatile__(
| ^
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r14' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r13' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r12' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r11' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r10' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r9' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r8' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%rdx' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%rcx' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%rbx' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%rax' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: output number 0 not directly addressable
```
After further investigation I found that for RISC-V, macro `USE_ASM_X86_64` was defined unexpectedly, and `checking for x86_64 assembly availability... yes` appeared in the compilation log file, which means `SECP_64BIT_ASM_CHECK` was not working as expected.
For unknown reasons, `AC_COMPILE_IFELSE` does not check if `__asm__` can be compiled, and an example can verify this point:
```m4
AC_DEFUN([SECP_64BIT_ASM_CHECK],[
AC_MSG_CHECKING(for x86_64 assembly availability)
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
#include <stdint.h>]],[[
__asm__ __volatile__("this is obviously wrong");
]])],[has_64bit_asm=yes],[has_64bit_asm=no])
AC_MSG_RESULT([$has_64bit_asm])
])
```
It always gives results: `checking for x86_64 assembly availability... yes`
After testing, replacing `AC_COMPILE_IFELSE` with `AC_LINK_IFELSE` can correctly check if `__asm__` can be compiled and make the project able to compile for RISC-V.
ACKs for top commit:
real-or-random:
ACK 7efc9835a9
Tree-SHA512: 7318dd42004b2930cfcd6541c5a9ce0aa186e2179a668b76089a908bea8d9f70fcfdb264512f971e395a3ce9dc7f9ca24c8f3d46175cad2972a2d713f518ed85
2f984ffc45 Save negations in var-time group addition (Peter Dettman)
Pull request description:
- Updated _gej_add_var, _gej_add_ge_var, _gej_add_zinv_var
- 2 fewer _fe_negate in each method
- Updated operation counts and standardize layout
- Added internal benchmark for _gej_add_zinv_var
benchmark_internal shows about 2% speedup in each method as a result (64bit).
ACKs for top commit:
real-or-random:
ACK 2f984ffc45
jonasnick:
ACK 2f984ffc45
Tree-SHA512: 01366fa23c83a8dd37c9a0a24e0acc53ce38a201607fe4da6672ea5618d82c62d1299f0e0aa50317883821539af739ea52b6561faff230c148e6fdc5bc5af30b
37d36927df tests: Add tests for _read_be32 and _write_be32 (Tim Ruffing)
616b43dd3b util: Remove endianness detection (Tim Ruffing)
8d89b9e6e5 hash: Make code agnostic of endianness (Tim Ruffing)
Pull request description:
Recent compilers compile the two new functions to very efficient code
on various platforms. In particular, already GCC >= 5 and clang >= 5
understand do this for the read function, which is the one critical
for performance (called 16 times per SHA256 transform).
Fixes#1080.
ACKs for top commit:
sipa:
utACK 37d36927df
robot-dreams:
ACK 37d36927df
Tree-SHA512: b03cec67756fb3c94ca8e7e06f974136050efd5065f392dba6eed4d0dbe61dbf93dad054627267225bac1bb302bb025f86588612ef7d4beeb834466686c70b8f
55512d30b7 doc: clean up module help text in configure.ac (Elliott Jin)
d9d94a9969 doc: mention optional modules in README (Elliott Jin)
Pull request description:
ACKs for top commit:
real-or-random:
utACK 55512d30b7
jonasnick:
ACK 55512d30b7
Tree-SHA512: ae4ec355730983117c5e9a8a8abd17aaf42afe6f8f8f7474a551df6269a62094883e0827d2f3642e3ed6eb26cf71982c20f7ac27498cb4bd7e4aea57ec308d6a
