Hello All,
I am trying to compile / install a utility from Source on CentOS that
utilizes OpenSSL 1.1.0 (latest version) . However, I get the following
error:
*configure: WARNING: Cannot find SSL_CTX_get0_param in libssl library. TLS
hostname verification will not be available.*
Kindly help
> I am trying to compile / install a utility from Source on CentOS that
> utilizes OpenSSL 1.1.0 (latest version) . However, I get the following error:
> configure: WARNING: Cannot find SSL_CTX_get0_param in libssl library. TLS
> hostname verification will not be available.
Most likely, the
I concur with Rich. CentOS is known for having outdated packages.
Regards,
Uri
Sent from my iPhone
On May 28, 2017, at 16:43, Salz, Rich via openssl-users
wrote:
>> I am trying to compile / install a utility from Source on CentOS that
>> utilizes OpenSSL 1.1.0
On Sun, May 28, 2017 at 2:59 AM, Mohit Batra wrote:
> Hello All,
>
> I am trying to compile / install a utility from Source on CentOS that
> utilizes OpenSSL 1.1.0 (latest version) . However, I get the following
> error:
>
> configure: WARNING: Cannot find SSL_CTX_get0_param
On Sun, May 28, 2017 at 5:16 PM, Hiran Chaudhuri
wrote:
> It seems I misread the referenced documentation the first time.
>
> This stuff contains the answer, it just was not clear to me that also works
> on Linux.
>
Quick reaction, I am impressed.
The part that triggered my wrong thoughts was the first sentence:
"RPATH's are supported by default on the BSD platforms, but not others."
It seemed platforms other than BSD will not get RPATH unless I take action.
With that in mind I somehow understood I need to
It seems I misread the referenced documentation the first time.
This stuff contains the answer, it just was not clear to me that also works
on Linux.
https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs.
With that, the libraries have run paths that show the correct
> The openssl program will use the wrong libssl.so and libcrypto.so.
Yes, got it.
But that's small potatoes compared to everyone else finding the wrong shared
library, and just saying "use rpath" doesn't help all those others.
--
openssl-users mailing list
To unsubscribe:
On Sun, May 28, 2017 at 5:25 PM, Salz, Rich wrote:
>> We still don't know what use case is being represented by omitting the
>> RPATH in the OpenSSL build.
>
> Because only one program, apps/openssl, presumably needs rpath. But that
> doesn't solve the problem for *external
On Sun, May 28, 2017 at 5:31 PM, Salz, Rich wrote:
>> The openssl program will use the wrong libssl.so and libcrypto.so.
>
> Yes, got it.
>
> But that's small potatoes compared to everyone else finding the wrong shared
> library, and just saying "use rpath" doesn't help all
> We still don't know what use case is being represented by omitting the
> RPATH in the OpenSSL build.
Because only one program, apps/openssl, presumably needs rpath. But that
doesn't solve the problem for *external applications* that need to find OpenSSL
in a different place, does it?
--
11 matches
Mail list logo