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