In message <CADqLbzKOvHz=JnAnFs+phLn9O_MSvVatCUZf-K3zZZS3A_Pp9g@xxxxxxxxxxxxxx> on Thu, 15 Feb 2018 11:00:00 +0300, Dmitry Belyavsky <beldmit@xxxxxxxxx> 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... Cheers, Richard -- Richard Levitte levitte@xxxxxxxxxxx OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
