[openssl-users] openssl 1.0.2 shared build's linking is not consistent - bin and libs linked to different libcrypto.so's

[h15234 at mailas.com]

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