[openssl-users] Building OpenSSL from sources

Dmitry Belyavsky beldmit at gmail.com
Fri Feb 16 07:59:04 UTC 2018

Dear Richard,

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

> 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>

More information about the openssl-users mailing list