我正在构build一个从应用程序（我无法控制）加载的共享库。 我的图书馆使用其他共享库，反过来使用其他共享库，复杂但并不罕见。
问题在于，主应用程序在链中的下一个库中存在函数，更具体地说，它是openLDAP ，它反过来使用openSSL函数：
Main app->My library->openLDAP libraries->openSSL libraries
我的猜测是，主要的应用是通过静态链接或简单的复制/粘贴源代码来实现openSSL 。
我的问题是：我可以控制哪些函数openLDAP使用从我的库或我必须重新编译openLDAP与静态链接到openSSL ？
由于安全问题， openSSL更新频率很高，如果不需要，我不需要静态副本。 为什么当它是大多数发行包的一部分时，重新分配一个专有的openLDAP副本…
现在你所拥有的是可执行文件，覆盖了系统默认选择的OpenSSL库。 这在可执行文件的权限之内，你不能真的阻止它。
静态链接库中的OpenSSL可能也不是真正的解决方案。 首先，如果可执行文件确实是使用不同的版本呢？ 另一方面，如果OpenSSL有一些全局变量呢？ 现在你将在同一个过程中拥有两个库，这不是一个好主意，可能会导致错误。
对我来说，我们在Linux上的最佳答案是不考虑这种事情是一个问题。 如果一个可执行文件加载了一个不好的OpenSSL版本，那不是你的库的错。 至多你可以检查哪个版本被加载，如果出于某种原因已知与你的库不兼容，则拒绝运行。
我的猜测是，主要的应用是通过静态链接或简单的复制/粘贴源代码来实现openSSL。
这是错误的事情。 如果应用程序开发者在他的脚上射击，那么你不能做任何事情。
应用程序开发人员应该看到你的库依赖于OpenSSL库（使用ldd命令），那么他不应该OpenSSL again as staticly or copy paste its code.链接OpenSSL again as staticly or copy paste its code.
如果OpenSSL中的某些函数不会产生任何混乱，并且可以像任何Java类的静态方法一样使用，那么只有App开发人员应该冒险在应用程序中实现该代码。
解决方法是在dlopen（3）中使用RTLD_DEEPBIND：
RTLD_DEEPBIND（自glibc 2.3.4开始）
将这个库中符号的查找范围放在全局范围之前。 这意味着一个独立的库将使用它自己的符号，优先于已经加载的库中包含的同名全局符号。 这个标志在POSIX.1-2001中没有被指定。
这可能不是最好的解决方案，但是当这个过程是由封闭的源代码软件创建的时候，它可以起作用。