> Setting *FLAGS & rpath, although the openssl binary links correctly
> against its own {libcrypto,libssl}.so, the libssl.so links against *system*,
> not its own, libcrypto.
You can verify the RPATHs are actually present by dumping the
DT_RUNPATH section of the ELF executable:
readelf -d <file> | grep -i RPATH
> What specific combination and settings of FLAGS are required to
> ensure that the bins & libs are all self-consistently linked/rpath'd only
> against this build's libs?
As far as I know, you only need an RPATH on Linux (OS X and Android
are a different story).
Your executable is probably missing it, so the link/loader first loads
the system libssl and libcrypto. After that, the link/loader considers
the dependency fulfilled and does not load your versions of the
libraries.
If you can't rebuild the executables, then consider using an
LD_LIBRARY_PATH (http://linux.die.net/man/8/ld-linux).
To avoid this on all platforms (DLL hell), I just link statically
against the OpenSSL libraries. Some consider it blasphemy, I consider
it peace of mind.
Jeff
On Tue, Mar 17, 2015 at 11:22 AM, <h15234 at mailas.com> wrote:
> I'm trying to build a library self-consistent instance of openssl 1.0.2 on linux/64.
>
> Setting *FLAGS & rpath, although the openssl binary links correctly against its own {libcrypto,libssl}.so, the libssl.so links against *system*, not its own, libcrypto.
>
> I've tried a bunch of combinations of *FLAGS. Always the same result. The current env/result is:
>
> cd ./openssl-1.0.2
>
> export SHARED_LDFLAGS="-L/usr/local/sslTEST/lib64 -Wl,-rpath,/usr/local/sslTEST/lib64 -lssl -lcrypto"
> export LDFLAGS=${SHARED_LDFLAGS}
> export LIBDEPS=${SHARED_LDFLAGS}
>
>
> ./config \
> --openssldir=/usr/local/sslTEST \
> --libdir=lib64 \
> threads shared zlib \
> enable-ec_nistp_64_gcc_128 \
> no-idea \
> no-ssl2 \
> no-rc5 \
> no-mdc2 \
> no-hw \
> no-ec2m \
> enable-rfc3779
>
> make depend
> make
> make install
>
> There are no apparent errors in the build output.
>
> The build results in
>
> /usr/local/sslTEST/bin/openssl version
> OpenSSL 1.0.2 22 Jan 2015
>
> ldd \
> /usr/local/sslTEST/bin/openssl \
> /usr/local/sslTEST/lib64/libssl.so.1.0.0 \
> /usr/local/sslTEST/lib64/libcrypto.so.1.0.0
>
> /usr/local/sslTEST/bin/openssl:
> linux-vdso.so.1 (0x00007ffefffd7000)
> libssl.so.1.0.0 => /usr/local/sslTEST/lib64/libssl.so.1.0.0 (0x00007f93cbe0e000)
> !! libcrypto.so.1.0.0 => /usr/local/sslTEST/lib64/libcrypto.so.1.0.0 (0x00007f93cb9ce000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f93cb77f000)
> libz.so.1 => /lib64/libz.so.1 (0x00007f93cb569000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f93cb1c1000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f93cc07a000)
>
> /usr/local/sslTEST/lib64/libssl.so.1.0.0:
> linux-vdso.so.1 (0x00007ffd01636000)
> !! libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007ff4abf33000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007ff4abd2f000)
> libz.so.1 => /lib64/libz.so.1 (0x00007ff4abb18000)
> libc.so.6 => /lib64/libc.so.6 (0x00007ff4ab771000)
> /lib64/ld-linux-x86-64.so.2 (0x00007ff4ac60d000)
>
> /usr/local/sslTEST/lib64/libcrypto.so.1.0.0:
> linux-vdso.so.1 (0x00007ffe1f55d000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f9a10f46000)
> libz.so.1 => /lib64/libz.so.1 (0x00007f9a10d30000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f9a10988000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f9a115d5000)
>
>
> where you can see the different libcrypto's are linked.
>
> Wht specific combination and settings of FLAGS are required to ensure that the bins & libs are all self-consistently linked/rpath'd only against this build's libs?
