链接器似乎忽略了库，默认为旧版本

Question

I've built a debug version of a shared library (OpenSSL) so I can step through a certain function with a debugger to better understand what's going on.

However, I'm having a difficult time actually linking with the debug version I've built. For some reason, no matter what I do, the linker always ends up linking with the pre-installed system version, even though both versions are in the usr/lib directory, the soft-links are setup correctly (AFAIK), and I explicitly specify the debug lib on the command line when compiling.

So the original (system-installed) version of the shared library is:

>ls /usr/lib/x86_64-linux-gnu/ -lh | grep libssl
lrwxrwxrwx 1 root root   15 Sep 23  2016 libssl.so -> libssl.so.1.0.0
-rw-r--r-- 1 root root 386K Sep 23  2016 libssl.so.1.0.0

And the debug version , which I compiled from source and configured as a shared library (using the fPIC flag for all object files), is:

 >ls /usr/lib/ -lh | grep libssl
lrwxrwxrwx  1 root root   29 Oct 19 11:31 libssldebug.so -> /usr/lib/libssldebug.so.1.0.2
-rwxr-xr-x  1 root root 2.3M Oct 19 00:53 libssldebug.so.1.0.2

And it's the same with the other OpenSSL shared library, libcrypto. I have a libcryptodebug.so.1.0.2 and a corresponding soft link in /usr/lib .

So, I try to build an executable and link against the debug shared lib like this:

 >g++ test.cpp -o test -std=c++14 -lssldebug -lcryptodebug -I openssl-1.0.2p/include/

And it compiles and links with no errors.

And YET... when I examine the executable with ldd , I see:

 >ldd test
        linux-vdso.so.1 (0x00007ffcaa39b000)
        libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007ff717d37000)
        libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007ff71793b000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff717630000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff71732f000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff717119000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff716d6e000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff716b6a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff717f98000)

So even though I explicitly linked with -lssldebug , and it compiled and linked with no errors, ldd still shows that the linker for some reason is linking with the non-debug version ( /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 ). I also tried running ldconfig and then recompiling/linking, but it still links with the old (non-debug) version.

So what is going on here? What am I doing incorrectly that causes it to silently ignore the command line linker arguments and somehow just default to using the non-debug version (which has a completely different shared lib name!) somehow?

Answer 1

So even though I explicitly linked with -lssldebug, and it compiled and linked with no errors, ldd still shows that the linker for some reason is linking with the non-debug version (/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

You are mixing up static linking, and runtime loading (sometimes also called dynamic linking).

When you link with g++ test.cpp ... -lssldebug ... , you are linking with libssldebug.so , but (as ldd output tells you) that library is not used during runtime loading.

That is happening because libssldebug.so has a special dynamic tag DT_SONAME , which contains "libssl.so.1.0.0" , and the static linker records that name as the library to be loaded at runtime.

You can confirm this with:

readelf -d libssldebug.so | grep SONAME

You can examine the libraries that runtime loader will try to locate for a given executable with:

readelf -d ./test | grep NEEDED

Now that you understand the problem, how do you fix it?

One of two ways:

1. You could change the SONAME encoded in libssldebug.so , by relinking it with -Wl,--soname=libssldebug.so.1.0.2 , and then relinking your test program. Use above readelf commands to verify that SONAME and NEEDED now contain "libssldebug.so.1.0.2" , and then ldd to verify that libssldebug.so.1.0.2 is what the runtime loader will use.
2. Alternatively, it may be simpler to install libssldebug.so into a different directory (say /tmp/libssldebug ), create a symlink libssl.so.1.0.0 -> lissldebug.so in that directory, and then ask the runtime loader to search this directory first with g++ test.cpp ... -Wl,--rpath=/tmp/libssldebug . With this solution, the executable will still search for libssl.so.1.0.0 , but it will search for it in the /tmp/libssldebug directory first , and will find your copy.