c++ - 我可以用静态版本替换共享库依赖项吗？

Question

我有一个依赖于 C++ 共享库 libfoo.so 的应用程序。我没有 libfoo.so 的源代码，只有描述其接口(interface)的头文件和共享库文件本身。 libfoo.so 被链接以包含 libbar.so.1 作为依赖项。我的应用程序也使用 libbar.so，但它使用 ABI 不兼容的修订版 libbar.so.2。

回顾一下，这里是依赖关系的粗略层次结构:

- myapp
    - libbar.so.2
    - libfoo.so
        - libbar.so.1

此设置会导致问题，因为我从两个 libbar 版本中获得多重定义的符号。 libbar 是一个开源库，我有它的静态库 libbar.a.1 可用。

是否可以修改或包装 libfoo.so，使其在运行时不再依赖于 libbar.so.1？具体来说，我考虑过做这样的事情:

• 创建一个包装器共享库 libfoowrapper.so 链接到 libfoo.so 和静态库 libbar.a.1 .

• 以某种方式隐藏 libbar.a.1 中的符号，这样它们就不会从 libfoowrapper.so 中导出。

• 以某种方式消除 libfoowrapper.so 及其二级依赖 libbar.so.1 之间的运行时依赖。

这可能吗？我目前在类 Unix 系统(Linux、MacOS)上使用 gcc，而将来我可能不得不在使用 Visual Studio 的 Windows 上使用它。

Answer 1

Is it possible to modify or wrap libfoo.so in such a way that it no longer depends upon libbar.so.1 at runtime?

否:大多数 UNIX 系统(AIX 除外)考虑 .so final 链接产品。无法进一步修改。

您确实有几个选择:

• 请libfoo.so 的“供应商”为您提供依赖于libbar.so.2 的最新拷贝。这是最好的解决方案。
• 不要直接依赖于 libfoo.so，而是使用 dlopen("libfoo.so", RTLD_LAZY|RTLD_LOCAL); 动态加载它。 RTLD_LOCAL 部分将确保 libfoo.so 位于单独的链接器命名空间中，并且 libbar.so.1 中的符号不​​会被使用libfoo.so 以外的任何内容。