tests.c: undefined reference to `ECSDA_SIG_get0` #836

issue xloem opened this issue on October 20, 2020

xloem commented at 1:25 PM on October 20, 2020: none

Build Options:
  with ecmult precomp     = yes
  with external callbacks = no
  with benchmarks         = yes
  with coverage           = no
  module ecdh             = no
  module recovery         = no
  module extrakeys        = no
  module schnorrsig       = no

  asm                     = x86_64
  bignum                  = gmp
  ecmult window size      = 15
  ecmult gen prec. bits   = 4

  valgrind                = no
  CC                      = gcc
  CFLAGS                  = -O2 -fvisibility=hidden -std=c89 -pedantic -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes -Wundef -Wno-unused-function -Wno-long-long -W
no-overlength-strings -W -g
  CPPFLAGS                = 
  LDFLAGS                 =

  CCLD     tests
src/tests-tests.o: In function `test_ecdsa_der_parse':
src/tests.c:4750: undefined reference to `ECDSA_SIG_get0'
src/tests.c:4751: undefined reference to `BN_is_negative'
src/tests.c:4751: undefined reference to `BN_is_negative'
collect2: error: ld returned 1 exit status

$ git rev-parse HEAD
c6b6b8f1bb044d7d1aa065ebb674adde98a36a8e
$ cat /etc/redhat-release 
Red Hat Enterprise Linux Workstation release 7.7 (Maipo)

elichai commented at 1:29 PM on October 20, 2020: contributor

Can you post the full configure output? it looks like it found openssl's headers but failed to link
xloem commented at 1:35 PM on October 20, 2020: none

I can do that in a bit. From what you said, though, it's relevant that I have openssl installed in /usr/local, and my ld doesn't automatically add /usr/local/lib64 to the linking path. I was bisecting to see when the error started: commit 90004586779d2c9e05f9b0e1730b1714ffef6cee builds fine for me without adding anything to LDFLAGS. I suspect adding my /usr/local/lib64 path to LDFLAGS will resolve it, and I'll post the full configure output soon if still needed.
xloem commented at 1:46 PM on October 20, 2020: none

I have an old openssl in /usr, and a newer openssl in /usr/local . Linking errors occur starting with 31abd3ab8d63a1e5623408e5fc73440579456a95 . Adding -L/usr/local/lib64 to LDFLAGS resolves it.

Here's the output without LDFLAGS, which fails: https://siasky.net/CADdCUHSSnGM3QQSKAv4Nr4FJnMvw0LHrFnKUxmaGM3DTg/configure.withoutldflags.log

Here's the output with LDFLAGS, which succeeds: https://siasky.net/CAAsW6rQZ1PAED5kp9F1nLYPGuWf4BFcXZV-UB1ip_C3HQ/configure.withldflags.log

I'm closing this bug because it seems specific to my system setup. More a bug in autotools, redhat, or ld than in this project.
xloem closed this on Oct 20, 2020
real-or-random commented at 1:49 PM on October 20, 2020: contributor

Note that this project uses OpenSSL only for some specific tests and benchmarks but none of the real code depends on OpenSSL, so you can simply configure --disable-openssl-tests and it won't use OpenSSL.
xloem commented at 1:51 PM on October 20, 2020: none

oh thanks that's super helpful
real-or-random cross-referenced this on Oct 20, 2020 from issue docs: Document dependencies in README by real-or-random
gmaxwell commented at 7:09 AM on October 21, 2020: contributor

The configure script shouldn't build with the openssl in this case either-- time to update the test to check those symbols.
real-or-random commented at 7:13 AM on October 21, 2020: contributor

Oh indeed. I didn't know that we check for the presence of the individual symbols. https://github.com/bitcoin-core/secp256k1/blob/887bd1f8b61857c091398358609d4fc180237a46/build-aux/m4/bitcoin_secp.m4#L48
real-or-random reopened this on Oct 21, 2020
elichai cross-referenced this on Oct 21, 2020 from issue Make autotools check for all the used openssl functions by elichai
real-or-random closed this on Oct 27, 2020

Contributors

Linked (view graph)

#837 docs: Document dependencies in README #838 Make autotools check for all the used openssl functions