Openssl 3.0.0
Russ Allbery
eagle at eyrie.org
Mon Sep 13 01:34:05 UTC 2021
Julien ÉLIE <julien at trigofacile.com> writes:
> 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
Looks like someone reported (correctly) an issue with using a prefix that
didn't already exist, and they "fixed" the issue by just assuming every
system uses the /lib64 convention. The comment that this commit deleted
explains why that code was there....
> 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/
Ah, this has gotten rather more muddled with usrmerge, I see. Prior to
usrmerge, /lib64 was a regular directory on Debian that contained a single
file (a symlink for the dynamic loader, which by Linux ELF convention is
in /lib64 although Debian doesn't otherwise use that path).
However, I suspect that /usr/lib64 does not exist, correct? It at least
doesn't on my system. So Autoconf will still detect that Debian doesn't
use lib64 and libraries should be installed in lib.
> 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
I think the answer is to always check for lib64 before lib when looking
for libraries, but preserve the current logic when installing libraries.
--
Russ Allbery (eagle at eyrie.org) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
More information about the inn-workers
mailing list