Tracing the reason an unexpected shared library is linked-in on Linux

18 Views Asked by At

I have an interesting little issue with 2 different versions of OpenSSL's libcrypto being linked in a specific application (a.out ;)), which leads to crashing.

I have OpenSSL v1.0, v1.1 and v3.1 installed, in separate subprefixes but with symlinks to the lib{ssl,crypto}.so.? runtime modules installed in the standard lib directory. This works fine in general because I provide accurate rpath information, and in the case of a.out I modified the build system so that the fully specified path to the desired libcrypto library is handed to the linker.

Still, I end up with libcrypto.so.1.0.0 linked to my executable in addition to the intended libcrypto.so.1.1. It is clearly not required because I can use patchelf to remove the unwanted dependency, which restores normal runtime behaviour.

My hunch is that one of the other dependencies somehow depends on libcrypto.so.1.0.0 but I already ran ldd on each of the dependencies listed by ldd a.out and none of them depends on libcrypto.so.1.0.0. Of course I might have to do this recursively for each of the dependencies (of the dependencies...) of the individual dependencies but that's getting a bit much to do manually. I've tried getting ld to tell me why it links that library but it doesn't (tell me, or actually link).

Are there any other ways to figure out why this unwanted dependency gets linked to my application? I presume ld.so might be able to tell me, but I cannot even find that executable on my system (?!).

0

There are 0 best solutions below