curl incorrectly reports openssl header/library version mismatch during configure

[satmandu]

I did this

Built curl with OpenSSL 3.0.1

I expected the following

Configure script should not warn about OpenSSL headers and library versions not matching in this case.

curl/libcurl version

[curl -V output]

/usr/local/share/musl/bin/curl -V
curl 7.81.0 (x86_64-pc-linux-musl) libcurl/7.81.0 OpenSSL/3.0.1 zlib/1.2.11 brotli/1.0.9 zstd/1.5.1 libidn2/2.3.2
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https mqtt pop3 pop3s smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli HSTS HTTPS-proxy IDN IPv6 Largefile libz SSL TLS-SRP UnixSockets zstd

operating system

(In a container so this isn't that relevant... Linux cheekon-x86_64 5.16.0-051600-generic #202201092355 SMP PREEMPT Mon Jan 10 00:21:11 UTC 2022 x86_64 GNU/Linux)

Relevant configure output:

checking for OpenSSL headers version... 3.0.1 - 0x301
checking for OpenSSL library version... 3.0.0
checking for OpenSSL headers and library versions matching... no
configure: WARNING: OpenSSL headers and library versions do not match.

Looks like OpenSSL will report the library version as 3.0.0 for all minor version updates of OpenSSL as per: openssl/openssl#17516

[bagder]

That output is totally harmless though and doesn't actually do anything.

[satmandu]

That output is totally harmless though and doesn't actually do anything.

So it appears, but when you're debugging building a static curl, you check every error message!

May just mention that it might be an issue, or that it might not be a problem?

Just trying to save someone some time in the future... 😅

[satmandu]

I guess this is a larger upstream question: openssl/openssl#17517

[jay]

I guess this is a larger upstream question: openssl/openssl#17517

That refers to runtime checks and the macro purposely avoids that due to cross compiling.

Ref: https://github.com/curl/curl/blob/curl-7_81_0/m4/curl-openssl.m4#L116

[bagder]

Yeah, that openssl issue is completely separate and independent from this configure check that I propose we simply remove (in #8280)