Dear Richard,
On Thu, Feb 15, 2018 at 11:48 AM, Richard Levitte <levitte@xxxxxxxxxxx> wrote:
-- In message <CADqLbzKOvHz=JnAnFs+phLn9O_MSvVatCUZf-K3zZZS3A_Pp9g@mail. > on Thu, 15 Feb 2018 11:00:00 +0300, Dmitry Belyavsky <beldmit@xxxxxxxxx> said:gmail.com
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
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
