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