<div dir="ltr">Dear Richard, <div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 15, 2018 at 11:48 AM, Richard Levitte <span dir="ltr"><<a href="mailto:levitte@openssl.org" target="_blank">levitte@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In message <CADqLbzKOvHz=<a href="mailto:JnAnFs%2BphLn9O_MSvVatCUZf-K3zZZS3A_Pp9g@mail.gmail.com">JnAnFs+phLn9O_<wbr>MSvVatCUZf-K3zZZS3A_Pp9g@mail.<wbr>gmail.com</a>> on Thu, 15 Feb 2018 11:00:00 +0300, Dmitry Belyavsky <<a href="mailto:beldmit@gmail.com">beldmit@gmail.com</a>> said:<br>
<br>
beldmit> Hello,<br>
beldmit><br>
beldmit> I get problems building and installing OpenSSL 1.1.0g from source. I use Debian Wheezy<br>
beldmit> (oldstable).<br>
beldmit><br>
beldmit> After running ./config; make; make test; sudo make install<br>
beldmit><br>
beldmit> I call /usr/local/bin/openssl<br>
beldmit><br>
beldmit> I get an error<br>
beldmit><br>
beldmit> /usr/local/bin/openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object<br>
beldmit> file: No such file or directory<br>
beldmit><br>
beldmit> $ ldd /usr/local/bin/openssl<br>
beldmit> libssl.so.1.1 => not found<br>
beldmit> libcrypto.so.1.1 => not found<br>
beldmit><br>
beldmit> This behavior differs from the one for version 1.1.0b, where everything works fine.<br>
beldmit><br>
beldmit> According to CHANGES in 1.1.0c<br>
beldmit><br>
beldmit> *) Removed automatic addition of RPATH in shared libraries and executables,<br>
beldmit> as this was a remainder from OpenSSL 1.0.x and isn't needed any more.<br>
beldmit> [Richard Levitte]<br>
beldmit><br>
beldmit> Could you please clarify why this changes were introduced?<br>
<br>
The change was made for a very specific reason, it screwed up testing,<br>
and here's how.<br>
<br>
On GNU systems (for example Linux), '-Wl,-rpath,/path/to/<wbr>installed/lib'<br>
sets DT_RPATH.  If you read the ld.so manual, you will see that<br>
DT_RPATH is used before anything else that affects what directories<br>
are looked into, including LD_LIBRARY_PATH.<br>
<br>
This meant that when running a new build of 'openssl' before<br>
installing it, it would look for a previously installed version of the<br>
libraries instead of those in the build directory.<br>
<br>
A solution that we did use was to use LD_PRELOAD, which comes before<br>
even DT_RPATH.  This worked well for quite a while.<br>
<br>
Enter asan and ubsan.  I don't remember which one it was, but I think<br>
it was one of those that was royally screwed up by our preloading the<br>
shared libraries in the build directory.  It simply didn't work.<br>
<br>
There is of course the solution to use '-Wl,--enable-new-dtags,-<wbr>rpath,<br>
/path/to/installed/lib', but that wouldn't work on older ELF systems<br>
<br>
Another factor in all of this is that the reason we used -rpath to<br>
begin with was that up until OpenSSL 1.0.2, we installed the libraries<br>
in a non-standard directory (/usr/local/ssl/lib) by default.  This is<br>
not longer so, the default location is /usr/local/lib, which should be<br>
one of the standard ld.so directories.<br>
<br>
In the end, we (or I, I don't remember) concluded that we didn't<br>
actually need a compulsary use of -rpath and that this should be left<br>
to the user.<br>
<br>
beldmit> Shouldn't the INSTALL file be changed to document this change<br>
beldmit> because the proposed way ( ./config; make; make test; make<br>
beldmit> install) does not work?<br>
<br>
Actually, this is documented, in NOTES.UNIX, which is mentioned in the<br>
beginning of INSTALL:<br>
<br>
<br>
 For additional platform specific requirements, solutions to specific<br>
 issues and other details, please read one of these:<br>
<br>
  * NOTES.UNIX (any supported Unix like system)<br>
  * NOTES.VMS (OpenVMS)<br>
  * NOTES.WIN (any supported Windows)<br>
  * NOTES.DJGPP (DOS platform with DJGPP)<br>
<br>
You see, INSTALL is supposed to be fairly platform agnostic...<br>
<br></blockquote><div><br></div><div>Thank you very much for your comprehensive explanation!</div><div><br></div><div>But doesn't it make sense to explicitly add invocation of ldconfig to make install scenario?</div><div><br></div><div><br></div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">SY, Dmitry Belyavsky</div>
</div></div>