When upgrading from 0.1_pre20201028 to 0.2.0 I get: libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I./src -O2 -std=c89 -pedantic -Wno-long-long -Wnested-externs -Wshadow -Wstrict-prototypes -Wundef -Wno-overlength-strings -Wall -Wno-unused-function -Wextra -Wcast-align -Wcast-align=strict -fvisibility=hidden -march=native -ggdb3 -O2 -pipe -fdiagnostics-color -c src/precomputed_ecmult.c -fPIC -DPIC -o src/.libs/libsecp256k1_precomputed_la-precomputed_ecmult.o libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I./src -O2 -std=c89 -pedantic -Wno-long-long -Wnested-externs -Wshadow -Wstrict-prototypes -Wundef -Wno-overlength-strings -Wall -Wno-unused-function -Wextra -Wcast-align -Wcast-align=strict -fvisibility=hidden -march=native -ggdb3 -O2 -pipe -fdiagnostics-color -c src/precomputed_ecmult_gen.c -fPIC -DPIC -o src/.libs/libsecp256k1_precomputed_la-precomputed_ecmult_gen.o libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I./src -DVALGRIND -O2 -std=c89 -pedantic -Wno-long-long -Wnested-externs -Wshadow -Wstrict-prototypes -Wundef -Wno-overlength-strings -Wall -Wno-unused-function -Wextra -Wcast-align -Wcast-align=strict -fvisibility=hidden -march=native -ggdb3 -O2 -pipe -fdiagnostics-color -c src/secp256k1.c -fPIC -DPIC -o src/.libs/libsecp256k1_la-secp256k1.o src/precomputed_ecmult.c:14:5: error: #error configuration mismatch, invalid ECMULT_WINDOW_SIZE. Try deleting precomputed_ecmult.c before the build. 14 | #error configuration mismatch, invalid ECMULT_WINDOW_SIZE. Try deleting precomputed_ecmult.c before the build. | ^~~~~ make[1]: *** [Makefile:1170: src/libsecp256k1_precomputed_la-precomputed_ecmult.lo] Error 1 make[1]: Leaving directory '/var/tmp/portage/dev-libs/libsecp256k1-0.2.0/work/secp256k1-0.2.0' make: *** [Makefile:891: all] Error 2 * ERROR: dev-libs/libsecp256k1-0.2.0::gentoo failed (compile phase): * emake failed Reproducible: Always
Created attachment 847332 [details] build.log
Created attachment 847334 [details] emerge --info
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=631bb82a245216ccf3cd8a23d2cd52c3dad1dadc commit 631bb82a245216ccf3cd8a23d2cd52c3dad1dadc Author: Sam James <sam@gentoo.org> AuthorDate: 2023-01-06 12:31:56 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-01-06 12:31:56 +0000 dev-libs/libsecp256k1: always delete pre-generated files Closes: https://bugs.gentoo.org/889844 Signed-off-by: Sam James <sam@gentoo.org> .../{libsecp256k1-0.2.0.ebuild => libsecp256k1-0.2.0-r1.ebuild} | 3 +++ 1 file changed, 3 insertions(+)
Building with USE=precompute-ecmult requires >43G memory. May be you have to add CHECKREQS_MEMORY="45G" for precompute-ecmult.
"precompute-ecmult" is a pessimization and should be removed. From developer Tim Ruffing: > And precompute-ecmult should probably be removed. I don't see what the purpose of this flag is. We always have precomputed ecmult tables and the only thing the USE flag currently does is increase these tables to a huge size, so huge that performance will suffer for sure (because the tables won't fit in the CPU cache). > > The defaults are 15 and 4, and they've been selected using careful benchmarks for desktop machines. Maybe you can squeeze out a few percents on your specific machine with something like (14,4) or (16,4) or similar if you really do the benchmarks. But (24,8) is insanely high and has no benefits. See: https://github.com/bitcoin-core/secp256k1/pull/1159#issuecomment-1323523530 I made this fix in the Bitcoin-Gentoo repository: https://gitlab.com/bitcoin/gentoo/-/commit/6e39601a748f3465f66a38e7989e7414a4a1d9c0 Should I be submitting pull requests to the main Gentoo repo rather than maintaining dev-libs/libsecp256k1 separately in Bitcoin-Gentoo? It looks as though improvements/fixes are not otherwise trickling down into the main repo.
(In reply to Matt Whitlock from comment #5) > Should I be submitting pull requests to the main Gentoo repo rather than > maintaining dev-libs/libsecp256k1 separately in Bitcoin-Gentoo? It looks as > though improvements/fixes are not otherwise trickling down into the main > repo. Yes please.
(In reply to Matt Whitlock from comment #5) > Should I be submitting pull requests to the main Gentoo repo https://github.com/gentoo/gentoo/pull/28990