C++ 解析C/C++；库版本冲突，主要在Linux上

我有一个大致如这里所示的情况；它在Windows和Linux上都存在，但我将使用Linux表示法来绘制它，这稍微清晰一些：

libbar.so.1和libbar.so.2包含名称和签名相同但行为不同的过程。如果我“天真地”链接应用程序，那么最后加载的库中的符号将“隐藏”第一个加载的库中的符号（至少，如果我理解正确的话），我无法同时使用这两个库，也无法确定当天实际使用的库中的符号

当然，我在运行时得到的错误消息与这个心智模型是一致的

现在，如果我可以重新编译所有库，那么正如参考中所述，我可以使用

–default symver

选项（至少在使用gcc编译和链接时）来完全消除每个库中符号的歧义，并强制libfoo.so查找函数

baz@@libbar.so.1

，并强制应用程序查找函数

baz@@libbar.so.2

，无歧义

但是，如果我只能重新编译我的应用程序和libbar.so.2呢？libfoo.so是否会忽略函数

baz@@libbar.so.2

，或者它看起来只不过是它的

baz

部分，并且可能仍然使用它而不是libbar.so.1中的函数

---

这是一个完全跨平台的应用程序，所以我在Windows上要解决完全相同的问题。在这里，我有一个线索，我可能能够使用SxS机制，因为情况与（比如）在VS2019中编译的应用程序链接到在VS2013中编译的库没有多大区别；因此，应用程序需要链接到运行时的一个版本，而库需要链接到另一个版本。但是，虽然我知道如何使用系统库来处理这个问题，但我不太确定如何使用其他库。

我想您已经考虑过使用

名称空间了。然后，您可以指出为什么它不是您的选项。将
libbar
移动到不同的名称空间肯定是最简单的跨平台方法solution@Damien如果这些是我自己的库，那么名称空间肯定是前进的方向。在本例中，两个“libbar”实际上是Python的两个不同版本，我希望避免对Python源代码进行范围太广的更改-至少在我用尽所有可能仅使用编译器标志来解决此问题之前是这样，您可能可以使用-Bsymbolic构建libbar.2，并使用dlopen和RTLD_LOCAL标志动态加载它，这样它将使其符号与其他共享库的符号完全分离。是的，我认为使用RTLD_DEEPBIND比-Bsymbolic更好，我只是忘记了这个选项。