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