[openssl-users] Building OpenSSL from sources

[Dmitry Belyavsky]

Dear Richard,

On Thu, Feb 15, 2018 at 11:48 AM, Richard Levitte <levitte at openssl.org>
wrote:

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

But doesn't it make sense to explicitly add invocation of ldconfig to make
install scenario?


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180216/4e3ab8ec/attachment-0001.html>