Daniel Gustafsson <daniel@yesql.se> writes:
> On 23 Oct 2023, at 08:22, Peter Eisentraut <peter@eisentraut.org> wrote:
>> The problem is that the binary might not match the library, so this could be very misleading. Also, meson gets the
versionvia pkg-config, so the result would also be inconsistent with meson. I am afraid this approach would be
unreliablein the really interesting cases.
> I tend to agree with this, it would be preferrable to be consistent with meson
> if possible/feasible.
The configure script doesn't use pkg-config to find OpenSSL, so that
would also risk a misleading result. I'm inclined to guess that
believing "openssl version" would be less likely to give a wrong
answer than believing "pkg-config --modversion openssl". The former
amounts to assuming that your PATH is consistent with whatever you
set as the include and library search paths. The latter, well,
hasn't got any principle at all, because we aren't consulting
pkg-config for this.
Also, since "PGAC_PATH_PROGS(OPENSSL, openssl)" prints the full path
to what it found, you can at least tell after the fact that you
are being misled, because you can cross-check that path against
the -L switches being used for libraries. I don't think there's
any equivalent sanity check available for what pkg-config tells us,
if we're not consulting that for the library location.
meson.build may be fine here --- I suppose the reason that gets
the version via pkg-config is that it also gets other build details
from there. It's slightly worrisome that the autoconf and meson
build systems might choose different openssl installations, but
that's possibly true of lots of our dependencies.
Another angle worth considering is that "openssl version" provides
more information. On my RHEL8 box:
$ pkg-config --modversion openssl
1.1.1k
$ openssl version
OpenSSL 1.1.1k FIPS 25 Mar 2021
On my laptop using MacPorts:
$ pkg-config --modversion openssl
3.1.3
$ openssl version
OpenSSL 3.1.3 19 Sep 2023 (Library: OpenSSL 3.1.3 19 Sep 2023)
regards, tom lane