In message <BD5F2F95-AB11-4B5F-9B91-E93C45AAC9EF@xxxxxxxxxxxx> on Thu, 18 May 2017 18:35:32 -0400, Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> said:
openssl-users>
openssl-users> > On May 18, 2017, at 4:08 PM, Richard Levitte <levitte@xxxxxxxxxxx> wrote:
openssl-users> >
openssl-users> > hiran.chaudhuri> Incidently, I think that when you do this, you'll find that it
openssl-users> > hiran.chaudhuri> finds
openssl-users> > hiran.chaudhuri> your libraries all right:
openssl-users> > hiran.chaudhuri>
openssl-users> > hiran.chaudhuri> $ ldd /prefix/openssl/bin/openssl
openssl-users> > hiran.chaudhuri>
openssl-users> > hiran.chaudhuri> Now this is interesting. Yes, openssl can find both the libraries
openssl-users> > hiran.chaudhuri> libssl and libcrypto. Would that imply that rpath is only a setting
openssl-users> > hiran.chaudhuri> for application (executables) but not for shared libraries?
openssl-users> > hiran.chaudhuri> In that case the test I tried would be totally meaningless.
openssl-users> >
openssl-users> > Yes, that's correct.
openssl-users>
openssl-users> NO, it is not correct, shared libraries also have rpaths for their
openssl-users> own dependencies. And when building OpenSSL for installation in
openssl-users> non-default locations (not /usr/lib and the like) the libraries
openssl-users> should have an rpath.
Err, it is correct insofar that it is how OpenSSL 1.0.2{x} is built.
It's possible it SHOULD be built differently, but that's a different
story. Here, the question was what's actually done.
(side note: BSD is treated differently, 'cause there was a time when
the RPATH setting in executable binaries didn't propagate down to the
libraries they loaded)
--
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
