builds with libressl on macOS fail

[bagder]

Our CI jobs that use cmake + libressl on macOS have all started to fail with this error output. Presumably they have changed libressl version that the curl build does not like?

The configure build using libressl fails as well, but only when building the examples(!)

cmake example build log

Undefined symbols for architecture x86_64:
  "_EVP_PKEY_get_bn_param", referenced from:
      _Curl_ossl_certchain in unity_0_c.c.o
  "_EVP_PKEY_get_id", referenced from:
      _Curl_ossl_certchain in unity_0_c.c.o
      _cert_stuff in unity_0_c.c.o
  "_OPENSSL_sk_num", referenced from:
      _Curl_ossl_certchain in unity_0_c.c.o
      _X509V3_ext in unity_0_c.c.o
      _cert_stuff in unity_0_c.c.o
      _ossl_verifyhost in unity_0_c.c.o
      _load_cacert_from_memory in unity_0_c.c.o
      _verifystatus in unity_0_c.c.o
  "_OPENSSL_sk_pop", referenced from:
      _cert_stuff in unity_0_c.c.o
  "_OPENSSL_sk_pop_free", referenced from:
      _cert_stuff in unity_0_c.c.o
      _load_cacert_from_memory in unity_0_c.c.o
  "_OPENSSL_sk_value", referenced from:
      _Curl_ossl_certchain in unity_0_c.c.o
      _X509V3_ext in unity_0_c.c.o
      _ossl_verifyhost in unity_0_c.c.o
      _load_cacert_from_memory in unity_0_c.c.o
      _verifystatus in unity_0_c.c.o
  "_SSL_CTX_set_options", referenced from:
      _ossl_connect_step1 in unity_0_c.c.o
  "_SSL_get1_peer_certificate", referenced from:
      _servercert in unity_0_c.c.o
      _verifystatus in unity_0_c.c.o
  "_X509_STORE_load_file", referenced from:
      _populate_x509_store in unity_0_c.c.o
  "_X509_STORE_load_path", referenced from:
      _populate_x509_store in unity_0_c.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[icing]

Just a interim report of current observations:

• the link errors are reported in make test, I assume because we static link the unit tests
• not all unit test linking fails. As seen in https://github.com/curl/curl/actions/runs/5499059260/jobs/10020987667
• first error is reported linking unit1305
• the building of unit1302 and others before that had no issues

I assume that unit1302 could be linked without dragging in the offending libcurlu_la-openssl.o and unit1305 through some dependencies needed it? But I am not certain here. Both init curl and construct an easy handle...

[icing]

Ok, now I can now longer build curl with ngtcp2 locally. Because it finds the wrong openssl. Which points in the same direction as this problem.

When I run:

gcc -DHAVE_CONFIG_H -I../include -I../lib  -isystem /opt/quic/openssl/include/ -I/opt/quic/include -c vquic/curl_ngtcp2.c -fno-common -DPIC -o vquic/.libs/libcurl_la-curl_ngtcp2.o

this fails. But when I run:

gcc -DHAVE_CONFIG_H -I../include -I../lib -I/opt/quic/openssl/include -I/opt/quic/include -c vquic/curl_ngtcp2.c -fno-common -DPIC -o vquic/.libs/libcurl_la-curl_ngtcp2.o

it works.

Output of echo | gcc -E -Wp,-v -:

clang -cc1 version 14.0.3 (clang-1403.0.22.14.1) default target x86_64-apple-darwin22.5.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /Library/Developer/CommandLineTools/usr/lib/clang/14.0.3/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.

/usr/local/include/openssl exists and is a standard OpenSSL from homebrew.

My understanding is that -isystem dir should use dir before the standard system includes, but that seems not to work any longer.