Linking against particular libssl

[Marc Glisse]

On Tue, 15 Apr 2014, Sahib Jakhar wrote:

> We have a build machine where two versions of libssl exist (one of
> them custom built - against which we want to link). However, no matter
> what we try, it is linking against the system's libssl. We have even
> gone to the extent of renaming system's libssl before running make.
> However ldd output still shows the same library.
>
>
>        # ldd <executable-name>
>        linux-vdso.so.1 =>  (0x00007fffc1842000)
>        librt.so.1 => /lib64/librt.so.1 (0x00000032fe200000)
>        libboost_filesystem.so.5 =>
> /usr/lib64/libboost_filesystem.so.5 (0x00000039a4800000)
>        libzip.so.1 => /usr/lib64/libzip.so.1 (0x00000039a3400000)
>        libuuid.so.1 => /lib64/libuuid.so.1 (0x0000003304200000)
>        libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5
> (0x00007ff28a9d2000)
>        libssl.so.1.0.0 => not found
>        libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x000000354ca00000)
>        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000039a3c00000)
>        libm.so.6 => /lib64/libm.so.6 (0x00000032fce00000)
>        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000039a3800000)
>        libc.so.6 => /lib64/libc.so.6 (0x00000032fd200000)
>        libpthread.so.0 => /lib64/libpthread.so.0 (0x00000032fda00000)
>        libboost_system.so.5 => /usr/lib64/libboost_system.so.5
> (0x00000039a5000000)
>        /lib64/ld-linux-x86-64.so.2 (0x00000032fca00000)
>        libz.so.1 => /lib64/libz.so.1 (0x00000039a3000000)
>        libdl.so.2 => /lib64/libdl.so.2 (0x00000032fd600000)
>
>
> As you can see above, in the executable it still refers
> libssl.so.1.0.0 though there is no such file. Even if we create a link
> named libssl.so.1.0.0 pointing to our custom library, same behavior is
> observed.
>
> The Makefile in use is as follows:
>
> 	CXX=g++
> 	CC=gcc
>
> 	STRIP=strip
>
> 	ARCH=$(shell uname)
>
> 	INCS = -I. -I../common -I../common/net -I./src -I./src/xxx
> 	CFLAGS += -pipe -DUNIX -DLINUX -D_LINUX
> 	LDFLAGS += -dynamic -lrt -lboost_filesystem -lzip -luuid
> -lboost_thread-mt /usr/lib64/libssl.so.10  /usr/lib64/libcrypto.so.10
>
>
> As you can see we are specifying the exact path to the libraries in
> LDFLAGS and we can see the same in g++ command line also during the
> build process but in the end the executable still ends up refering to
> the other library.
>
> The relevant ls command output is as follows (after renaming the
> offending libssl):
>
> # ls -l /usr/lib64/libssl*
> -rwxr-xr-x. 1 root root 244872 Apr 16  2012 /usr/lib64/libssl3.so
> lrwxrwxrwx. 1 root root     39 Apr 10 11:56 /usr/lib64/libssl.so.10 ->
> /usr/local/ssl/fips/lib/libssl.so.1.0.0
> lrwxrwxrwx. 1 root root     12 Apr 14 21:21 /usr/lib64/libssl.so.1.0.0
> -> libssl.so.10

What is the SONAME of /usr/lib64/libssl.so.10? (you can try objdump to see 
it)

-- 
Marc Glisse