Re: Openssl 3.0.0

Julien ÉLIE <[email protected]> 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 ([email protected])             <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.
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers