Linux, a shared library uses functions from the main program instead of other shared libraries

I am creating a shared library loaded from an application (which I do not control). My library uses other shared libraries, which, in turn, use other shared libraries, complex but not unusual.

The problem is that the main application has functions that are present in one of the libraries located further in the chain, more specifically, this openLDAP, in turn, uses functions openSSL:

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

I assume that the main application implements openSSLeither a static link or a simple copy / paste of the source code.

My question is: can I control which functions I openLDAPuse from my library, or do I need to recompile openLDAPwith static binding to openSSL?

Since it openSSLupdates quite often due to security issues, I do not need a static copy if I do not need it. And why redistribute a proprietary copy openLDAPwhen it is part of most distribution packages ...

+4
source share
3 answers

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

RTLD_DEEPBIND (since glibc 2.3.4)

. , . POSIX.1-2001.

, , .

0

, , OpenSSL . , .

OpenSSL . -, , ? , , OpenSSL ? , .

, Linux, . OpenSSL, . , , - .

+3

, openSSL / .

. , .

The application developer should see that your library depends on the OpenSSL library (using the ldd command), then it should not link OpenSSL again as staticly or copy paste its code.

If some functions of OpenSSL do not create any messy ones and if they can be used in the same way as any static method of any java class, then only the application developer should risk implementing this code in the application.

0
source

All Articles