Issue compiling on OpenBSD 6.7

fanquake commented at 1:20 pm on July 20, 2020: member

Since the secp256k1 subtree update in https://github.com/bitcoin/bitcoin/pull/19228, it hasn’t been possible to cleanly compile Bitcoin Core on OpenBSD. Building fails with (excerpt from just building libsecp, cc is Clang 8.0.1):

0./autogen.sh
1./configure CC=cc MAKE=gmake
2gmake -j6 V=1
3...
4gmake
5gcc -I. -I./src -Wall -Wextra -Wno-unused-function -g -c src/gen_context.c -o gen_context.o
6In file included from src/gen_context.c:16:
7src/util.h:179: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'uint128_t'
8gmake: *** [Makefile:1689: gen_context.o] Error 1

libsecp does some native compiler detection in configure, and then uses that compiler specifically for the ecmult precomputation. i.e: https://github.com/bitcoin-core/secp256k1/blob/3f4a5a10e43bfc8dae5b978cb39aa2dfbaf4d713/configure.ac#L186-L188 and then: https://github.com/bitcoin-core/secp256k1/blob/3f4a5a10e43bfc8dae5b978cb39aa2dfbaf4d713/Makefile.am#L129-L130

The problem is that this ends up picking up and using OpenBSDs GCC 4.2.1, which barfs when it gets to util.h: https://github.com/bitcoin-core/secp256k1/blob/3f4a5a10e43bfc8dae5b978cb39aa2dfbaf4d713/src/util.h#L179

I realise there might not be much that can be done here, given that it’s the AX_PROG_CC_FOR_BUILD macro that is returning gcc to use. However thought I’d open an issue here for any thoughts, before we update our docs. I’ve suggested that affected users can just pass CC_FOR_BUILD=cc to configure when building. Issue here: https://github.com/bitcoin/bitcoin/issues/19559.

real-or-random commented at 5:02 pm on July 20, 2020: contributor

I realise there might not be much that can be done here, given that it’s the AX_PROG_CC_FOR_BUILD macro that is returning gcc to use.

Okay, I believe that’s really just a bug. The problem is that all of this is a little bit hacky (because autoconf is a huge hack for the C mess and is hacky by itself) and annoying. I just don’t see why this issue didn’t appear in earlier revisions.

So we call AC_CHECK_TYPES([__int128]) [1], which defines HAVE___INT128 if the type exists. This check is performed against the selected CC but the result is not only used for CC but also for CC_FOR_BUILD, which should be entirely independent.

The definition is imported here then: https://github.com/bitcoin-core/secp256k1/blame/3f4a5a10e43bfc8dae5b978cb39aa2dfbaf4d713/src/gen_context.c#L10 I believe the goal of including the basic config below that line is to make sure we compile gen_context with the most simple config that should run everywhere. (And performance does not matter anyway, it returns immediately and its running time is just compilation time in the end.)

So I believe the simple way to fix this is to add #undef HAS___INT128 to the list of undefs in src/basic-config.h. Can you check if this solves the issue?

[1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Generic-Types.html#Generic-Types

fanquake commented at 2:16 am on July 21, 2020: member

Can you check if this solves the issue?

Sure. I assume you meant #undef HAVE___INT128. I tested with 3f4a5a10e43bfc8dae5b978cb39aa2dfbaf4d713 + this diff:

 0diff --git a/src/basic-config.h b/src/basic-config.h
 1index e9be39d..3ad77c2 100644
 2--- a/src/basic-config.h
 3+++ b/src/basic-config.h
 4@@ -9,6 +9,7 @@
 5 
 6 #ifdef USE_BASIC_CONFIG
 7 
 8+#undef HAVE___INT128
 9 #undef USE_ASM_X86_64
10 #undef USE_ECMULT_STATIC_PRECOMPUTATION
11 #undef USE_ENDOMORPHISM

 0./autogen.sh
 1./configure CC=cc MAKE=gmake
 2....
 3Build Options:
 4  with endomorphism       = no
 5  with ecmult precomp     = yes
 6  with external callbacks = no
 7  with benchmarks         = yes
 8  with coverage           = no
 9  module ecdh             = no
10  module recovery         = no
11
12  asm                     = x86_64
13  bignum                  = no
14  field                   = 64bit
15  scalar                  = 64bit
16  ecmult window size      = 15
17  ecmult gen prec. bits   = 4
18
19  valgrind                = no
20  CC                      = cc
21  CFLAGS                  = -O2 -fvisibility=hidden -std=c89 -pedantic -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes -Wno-unused-function -Wno-long-long -Wno-overlength-strings -W -g
22  CPPFLAGS                = 
23  LDFLAGS                 = 
24...
25gmake check -j6
26...
27PASS: exhaustive_tests
28PASS: tests

Everything seems to be working ok.

real-or-random referenced this in commit 22e578bb11 on Jul 21, 2020

real-or-random cross-referenced this on Jul 21, 2020 from issue Undef HAVE___INT128 in basic-config.h to fix gen_context compilation by real-or-random

real-or-random commented at 12:24 pm on July 21, 2020: contributor

Ok, thanks, this PR should fix it then. We could also let the autoconf script to do the following

If CC_FOR_BUILD is set externally, use this
Otherwise try to use CC as CC_FOR_BUILD
Only if this fails, use the autodetected

It’s somewhat surprising that GCC is used when you set CC to clang. We could also just note this in the “Build steps” section in the README.

jonasnick closed this on Jul 21, 2020

fanquake commented at 0:17 am on July 22, 2020: member

Ok, thanks, this PR should fix it then.

Great. Thanks for the quick followup and fix.

real-or-random referenced this in commit 5cac98b3b7 on Jan 2, 2021

real-or-random referenced this in commit 517c44c271 on Jan 2, 2021

real-or-random referenced this in commit 3c15130709 on Jan 8, 2021

Issue compiling on OpenBSD 6.7 #768