compile error when openssl@3 is installed in the system

[xxchan]

  = note: ld64.lld: error: undefined symbol: SSL_get1_peer_certificate
          >>> referenced by rdkafka_ssl.c:560 (/Users/xxchan/.cargo/git/checkouts/rust-rdkafka-545566655b063b24/8ea07c4/rdkafka-sys/librdkafka/src/rdkafka_ssl.c:560)
          >>>               /Users/xxchan/Projects/risingwave/target/debug/deps/librdkafka_sys-ac5dc6115a3c07e2.rlib(rdkafka_ssl.c.o):(symbol rd_kafka_transport_ssl_verify+0x54)
          >>> did you mean: SSL_get_peer_certificate
          >>> defined in: /Users/xxchan/Projects/risingwave/target/debug/deps/libopenssl_sys-51e6e710cf1b233f.rlib(ssl_lib.o)
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

SSL_get_peer_certificate is deprecated in OpenSSL@3, and defined as

/* Deprecated in 3.0.0 */
#  ifndef OPENSSL_NO_DEPRECATED_3_0
#   define SSL_get_peer_certificate SSL_get1_peer_certificate
#  endif
# endif

Apparently, although we use openssl/vendored (which is OpenSSL@1 now), the C++ lib librdkafka (built by cmake) somehow found OpenSSL@3 installed in the system. When we link the final binary, the problem occurs.

possible reasons:

• brew openssl isn't keg-only any more Homebrew/homebrew-core@501a8a7

The solution is quite easy:
unset OPENSSL_ROOT_DIR and/or brew unlink openssl

[xxchan]

The reason why it breaks is quite clear.

What confused me most is that IIRC previously when OPENSSL_ROOT_DIR is set, it can still compile, but it can't now. I tried a while but cannot find when the regression happens. Or is my memory wrong??

[xxchan]

I think it's a not big problem, as OpenSSL 1.1 will reach EOL this September. 😅 We can wait for sfackler/rust-openssl#1925 and problems should be less likely to occur.

[xxchan]

Alternatively, what about use system openssl directly, since brew made it available by default? 😅

[xxchan]

BTW, to create portable binary (static link OpenSSL), we don't have to use vendored. We can use OPENSSL_STATIC instead. 🤣 cc #9852

[xxchan]

openssl-src uses openssl 3 now, so I believe this issue will be less likely to occur.