This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linking against particular libssl


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]