Linking against particular libssl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux