[openssl-dev] [openssl.org #3846] [bug] openssl 1.0.2 shared build's linking is not consistent - bin and libs linked to different libcrypto.so's

[h15234@mailas.com via RT]

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.

a workaround is to just ignore it -- and fix the link AFTER the build's done.

Noting 

	On Tue, Apr 7, 2015, at 07:06 PM, Jeffrey Walton wrote:
	> As far as I know, you only need an RPATH on Linux (OS X and Android
	> are a different story).

After the build, since there's no proper RPATH for the libssl.so with any combination of FLAGs that I've been able to figure out,

	ldd libssl.so.1.0.0 | egrep "ssl|crypto"
	        libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0 (0x00007f55e46c0000)
	readelf --dynamic libssl.so.1.0.0 | egrep -i "rpath|runpath"
		(empty)

For anyone actually interested this does the trick

	patchelf --set-rpath "/path/to/ssl/lib" --force-rpath libssl.so.1.0.0
	readelf --dynamic libssl.so.1.0.0 | egrep -i "rpath|runpath"
		0x000000000000000f (RPATH)              Library rpath: [/path/to/ssl/lib]

	ldd libssl.so | egrep "ssl|crypto"
	        libcrypto.so.1.0.0 => /path/to/ssl/lib/libcrypto.so.1.0.0 (0x00007f476b4fc000)