Linux，共享库使用主程序中的函数而不是其他共享库

Question

I'm building a shared library that is loaded from an application (which I have no control of). My library uses other shared libraries which in turn uses other shared libraries, complex but not unusual.

The problem is that the main application have functions present in one of the libraries further down in the chain, to be more specific it is openLDAP that in turn uses openSSL functions:

Main app->My library->openLDAP libraries->openSSL libraries

My guess is that the main application is implementing openSSL either by a static linkage or a simple copy/paste of source code.

My question is: can I control which functions openLDAP uses from my library or do I have to recompile openLDAP with a static linkage to openSSL ?

Since openSSL is updated quite frequently due to security issues I don't want a static copy of it if I don't have to. And why re-distribute a proprietary copy of openLDAP when it's part of most distributions packages...

Answer 1

Right now what you have is the executable overriding what would otherwise be the system's default choice of OpenSSL library. It is within the executable's rights to do that, and you can't really stop it.

Statically linking OpenSSL in your library may not really be a solution either. For one thing, what if the executable really does was to use a different version? For another, what if OpenSSL has some global variables? Now you will have two copies of the library in the same process, which is not a good idea and may cause bugs.

To me, the best answer we have on Linux is to not consider this sort of thing to be a problem. If an executable loads a bad version of OpenSSL, that is not your library's fault. At most you can check which version is loaded and refuse to run if it's known to be incompatible with your library for some reason.

Answer 2

My guess is that the main application is implementing openSSL either by a static linkage or a simple copy/paste of source code.

This is wrong things. If application developer shoots on his foot then you can not do anythings.

App developer should see that your library is dependent on OpenSSL library (using ldd command) then he should not link OpenSSL again as staticly or copy paste its code.

If some functions from OpenSSL does not creating any messy and if they can be used just like any static method of any java class then only App developer should take risk of implementing that code in app.

Answer 3

The solution was to use RTLD_DEEPBIND in dlopen(3):

RTLD_DEEPBIND (since glibc 2.3.4)

Place the lookup scope of the symbols in this library ahead of the global scope. This means that a self-contained library will use its own symbols in preference to global symbols with the same name contained in libraries that have already been loaded. This flag is not specified in POSIX.1-2001.

This might not be the the best solution but it works in this case when the process is created by closed source software.