c-在主程序中使用不同的共享库，并在程序中加载so

我的主程序需要调用标准的openssl函数，如

SSL\u library\u init（）

。另一方面，程序需要加载一个库，比如mylib.so，该库使用修改后的openssl版本

主程序是使用

-L/path-to/orig-openssl/lib -lssl -lcrypto

此外，mylib.so是使用

-Wl,-rpath,/path-to/modified-openssl/lib -Wl,-Bsymbolic

选项

当我执行程序时，它会尝试加载openssl的修改版本，而不是原始版本

如何强制程序在主程序中使用原始openssl，而在调用的库mylib.so中使用修改后的版本

注1：如果我使用

-rpath、/path to/orig openssl/lib

编译程序，程序将加载真实（原始）的openssl。但是，当它尝试加载mylib.so时，它失败了（dlopen无法打开库）

注2：在

dlopen

函数中使用

RTLD\u DEEPBIND

标志会导致相同的结果

如何强制程序在主程序中使用原始openssl，而在调用的库mylib.so中使用修改后的版本

简而言之，你不能

没有办法可靠地完成你的要求

您的代码与

mylib.so

（需要自定义版本的OpenSSL）的要求之间存在冲突，而您的代码需要“正常”版本的OpenSSL

OpenSSL的设计不允许在单个进程中存在多个不同的实例。会出现不可预测的符号冲突，例如，期望函数或变量完成某件事或成为某件事的代码会得到一个函数或变量的符号，而该函数或变量完成了某件事或是另一件事，例如，期望不同参数或具有不同字段的结构的函数

即使您以某种方式设法使事情看起来正常工作，但如果由于新的漏洞而必须升级OpenSSL版本，并且该升级破坏了您的解决方案，您将怎么做？你找不到一种方法来修复它们，让事情重新“运转”起来？（我希望您不要忽视使用修改后的OpenSSL版本升级OpenSSL的必要性-当OpenSSL中的下一个高优先级安全相关漏洞发布时，您如何计划推出一个针对该漏洞的紧急修复程序？）

如果您必须使用两个不同版本的OpenSSL，则需要从两个单独的进程中执行此操作。

自我回答：

使用带有

LM\u ID\u NEWLM

标志的

dlmopen

在主程序中加载mylib.so

---

此外，要编译主程序，请使用

-Wl，-rpath，/path to/orig openssl/lib

进行动态链接。换句话说，您应该为共享对象和主程序设置rpath。

为lib使用静态链接将修改过的包（如此包）合并到代码中从来都不是一个好主意。如果您需要此库未提供的其他功能，请创建您自己的补充库，注意将自定义库的命名约定与原始库分开。