Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Openssl 3.0.0 (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Fri, 10 Sep 2021 15:28:24 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Openssl 3.0.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
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)
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 133, Issue 5
*******************************************
