Openssl 3.0.0

[Julien ÉLIE]

Hi Russ,

>> is there a reason why lib-pathname.m4 checks for /usr/lib32 or
>> /usr/lib64 only?  I suggest to also add a check for /lib32 or /lib64.
>> With the following patch, configure correctly finds
>> /home/iulius/work/openssl-3.0.0/lib64 Note that I have /lib64 but not
>> /usr/lib64 on an (old) Jessie Debian system.  Seems like newer versions
>> have both.
> 
> Debian does not use /lib64 paths, so it's correct to not detect this on
> Debian.  (They're explicitly forbidden by Debian Policy in favor of using
> multiarch.)  This seems like a bug in OpenSSL that nontheless it installed
> itself in <prefix>/lib64, presumably assuming the whole world is Red Hat.

It was indeed a late change in July 2021 before the final OpenSSL 3.0.0 
release:
   https://github.com/openssl/openssl/issues/16121
 
https://github.com/openssl/openssl/commit/74b7f339aa58af57c0e71b7efca66e6f2db5ae2e

Prior to OpenSSL 3.0.0, <prefix>/lib was always used; now it is 
<prefix>/lib{,32,64}.



> I assume you were using --with-openssl.  You can work around this
> with --with-openssl-libs, but it would probably be better if you
> didn't have to if OpenSSL does this everywhere.
Yes, I was using --with-openssl=/home/iulius/work/openssl-3.0.0

Now, I have to use both --with-openssl=/home/iulius/work/openssl-3.0.0 
--with-openssl-lib=/home/iulius/work/openssl-3.0.0/lib64 as you say, for 
the build to work on Jessie.


On Debian Buster, I see symlinks for /libXX to /usr/libXX

lrwxrwxrwx   1 root root    7 Jan  8  2021 lib -> usr/lib/
lrwxrwxrwx   1 root root    9 Jan  8  2021 lib32 -> usr/lib32/
lrwxrwxrwx   1 root root    9 Jan  8  2021 lib64 -> usr/lib64/
lrwxrwxrwx   1 root root   10 Jan  8  2021 libx32 -> usr/libx32/

so the build would work fine without --with-openssl-lib

The issue comes with at least (old) Debian Jessie where I have /lib, 
/lib64 (with only ld-linux-x86-64.so.2 inside) and /usr/lib (without 
/usr/lib64).



> If we want to work around this bug, we need different logic for
> RRA_SET_LDFLAGS than for RRA_SET_LIBDIR, since it's incorrect on this
> system for the latter to use /lib64, but the former should presumably fall
> back to /lib64 if /lib is not present.

Yes, the fix is more complex than suggested in my previous message.
In the GCC C Farm, I for instance see Alpine with /lib and /usr/lib only 
but OpenSSL configure sets LIBDIR=lib64
So indeed the current logic when we set LDFLAGS without explicit 
--with-xxx-lib=<path> is broken with the new behaviour of OpenSSL 
3.0.0...  And maybe other software, I do not know.

-- 
Julien ÉLIE

« La vérité pure et simple est très rarement pure et jamais simple. »
   (Oscar Wilde)