On Tue, Apr 7, 2015, at 07:06 PM, Jeffrey Walton wrote:
> > 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
Here
readelf -d `which openssl` | egrep -i "rpath|ssl|crypto"
0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.0.0]
0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.0.0]
0x000000000000001d (RUNPATH) Library runpath: [/usr/local/ssl/lib64]
> > 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.
Hm, confused. This
export SHARED_LDFLAGS="-L/usr/local/sslTEST/lib64 -Wl,-rpath,/usr/local/sslTEST/lib64 -lssl -lcrypto"
is supposed to take care of the rpath. Apparently not.
"Your executable is probably missing it" ... from where? How/where else to specify?
> If you can't rebuild the executables, then consider using an
> LD_LIBRARY_PATH (http://linux.die.net/man/8/ld-linux).
I avoid run-time path'ing whenever possible
> 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.
The thought's crossed my mind. But higher powers here have deemed it blasphemous.
Thanks
Hanlon
