Linking against particular libssl

Sahib Jakhar sahib.jakhar@gmail.com
Tue Apr 15 08:37:00 GMT 2014


Hi,

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

# ls -l /usr/lib64/libcrypto*
-rw-r--r--. 1 root root 4517344 Apr 10 10:39 /usr/lib64/libcrypto.a
-rw-r--r--. 1 root root      20 Apr 10 11:56 /usr/lib64/libcrypto.hmac
lrwxrwxrwx. 1 root root      42 Apr 10 11:56 /usr/lib64/libcrypto.so
-> /usr/local/ssl/fips/lib/libcrypto.so.1.0.0
lrwxrwxrwx. 1 root root      42 Apr 14 22:21
/usr/lib64/libcrypto.so.10 ->
/usr/local/ssl/fips/lib/libcrypto.so.1.0.0
-rwxr-xr-x. 1 root root 2713220 Apr 10 11:56 /usr/lib64/libcrypto.so.1.0.0


Just to reiterate, we want to link against libssl.so.10 and
libcrypto.so.10. So it should come like this,

        # 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.10 => /usr/lib64/libssl.so.10
        libcrypto.so.10 => /usr/lib64/libcrypto.so.10
        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)


Can somebody please explain what are we doing wrong (if anything), and
how we can resolve this?


Thanks for you consideration,
SJ



More information about the Gcc-help mailing list