Hi All,
Thanks for all your response.
I have tried to set LD_LIBRARY_PATH to the lib path of newly installed openssl and still "./openssl version" fails with the same reason.
There is another suggestion to "compile with a RUNPATH set in the
output ELF files. " . Could anyone please provide more details about this and how to do it ? Thanks and Regards,
Ram Krushna
On Sat, Mar 16, 2019 at 6:20 AM <openssl-users-request@xxxxxxxxxxx> wrote:
Send openssl-users mailing list submissions to
openssl-users@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
openssl-users-request@xxxxxxxxxxx
You can reach the person managing the list at
openssl-users-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."
Today's Topics:
1. Re: Reg solaris support for openssl 1.1.1b (Jakob Bohm)
5. Re: Reg solaris support for openssl 1.1.1b (Dennis Clarke)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 Mar 2019 18:19:53 +0100
From: Jakob Bohm <jb-openssl@xxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Re: Reg solaris support for openssl 1.1.1b
Message-ID: <649ef06e-0f64-65bb-cb43-cfde681fd117@xxxxxxxxxx>
Content-Type: text/plain; charset=utf-8; format=flowed
On 15/03/2019 14:33, Dennis Clarke wrote:
> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>> My guess is that your binary is loading the system's shared libraries.
>> To find out whether this is the case, try
>>
>> ??? ldd bin/openssl
>>
>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>> explicitely.
> Actually LD_LIBRARY_PATH is evil.
>
> The correct way to do this is to compile with a RUNPATH set in the
> output ELF files.
LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
testing
a newly compiled binary before installing the libraries to their final
locations, perhaps
on the same, perhaps on another machine.
P.S.
I don't known if the Solaris loader lets LD_LIBRARY_PATH override
RUNPATH as
presumed by the above answer.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
------------------------------
Message: 5
Date: Fri, 15 Mar 2019 20:49:30 -0400
From: Dennis Clarke <dclarke@xxxxxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Re: Reg solaris support for openssl 1.1.1b
Message-ID: <4b08232c-f734-987c-814c-5acef59f42ab@xxxxxxxxxxxxx>
Content-Type: text/plain; charset=utf-8
On 3/15/19 1:19 PM, Jakob Bohm via openssl-users wrote:
> On 15/03/2019 14:33, Dennis Clarke wrote:
>> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>>> My guess is that your binary is loading the system's shared libraries.
>>> To find out whether this is the case, try
>>>
>>> ???? ldd bin/openssl
>>>
>>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>>> explicitely.
>> Actually LD_LIBRARY_PATH is evil.
>>
>> The correct way to do this is to compile with a RUNPATH set in the
>> output ELF files.
> LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
> testing
> a newly compiled binary before installing the libraries to their final
> locations, perhaps
> on the same, perhaps on another machine.
>
> P.S.
> I don't known if the Solaris loader lets LD_LIBRARY_PATH override
> RUNPATH as
> presumed by the above answer.
Yes it certainly does. Otherwise testing a new custom lib would be a
royal pain as opposed to just a pain. Also most people still, after
twenty years, know what LD_LIBRARY_PATH env var is for and it is a waste
of breath trying to explain it after decades of watching folks skewer
themselves over and over and over ....
dc
------------------------------
Subject: Digest Footer
_______________________________________________
openssl-users mailing list
openssl-users@xxxxxxxxxxx
https://mta.openssl.org/mailman/listinfo/openssl-users
------------------------------
End of openssl-users Digest, Vol 52, Issue 19
*********************************************
