In message <bd5f2f95-ab11-4b5f-9b91-e93c45aac...@dukhovni.org> on Thu, 18 May
2017 18:35:32 -0400, Viktor Dukhovni <openssl-us...@dukhovni.org> said:
openssl-users>
openssl-users> > On May 18, 2017, at 4:08 PM, Richard Levitte
<levi...@openssl.org> 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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
