两个插件链接到具有不同实现（代码）的同名 DLL 或共享库对象（so）答案

【问题标题】：Two plugins linking to identically named DLLs or shared library object (so) with different implementation (code)两个插件链接到具有不同实现（代码）的同名 DLL 或共享库对象（so）
【发布时间】：2012-04-25 17:22:38
【问题描述】：

我有两个“插件”（为了讨论起见，将它们视为软件包中的两个不同应用程序）动态链接到我的库的两个单独构建的版本。我的代码是用 C++ 编写的，并且始终使用一致的命名空间。有时我必须建立两个不同的每个应用程序的版本。当两个应用程序（插件）时，这似乎会导致一些问题在包中同时加载。首先，我需要帮助了解为什么会发生此错误。

例如，我有两个独立但名称相同的库，比如mylib.so（或 DLL），每个应用程序都链接到其中一个（唯一）。如果mylib.so 中的底层代码相同（即命名空间、函数名称等，当然实现略有不同），这会导致问题吗？库的两个副本位于独特的位置这一事实是否足以避免由于歧义或其他链接错误而可能出现的任何问题？我认为显然不是......但我想听听专家的意见。

假设上面的描述是导致问题的原因，只会更改库的名称以包含一些版本信息，例如，mylib_v1.so 和 mylib_v2.so 提供对歧义错误的保护（底层函数/命名空间名称是仍然相同）？我仍然认为不是..但这次我不确定。假设我是对的，那么在我的代码中使用一些宏来更改命名空间以在命名空间中包含版本信息（例如，namespace mystuff {} 更改为 namespace mystuff_v1）至少可以解决问题吗？感谢您的见解。

注意：令人惊讶的是，歧义只发生在 Windows 上！ Linux 能够毫无问题地处理第二段中的情况。

【问题讨论】：

标签： c++ windows linux dll ambiguous

【解决方案1】：

如果应用程序唯一地只使用一个，并且设置了 PATH 和 LD_LIBRARY_PATH 让他们不见面就没有冲突。你可以看到数百个类似的 msvcrt.dll 文件曾经与应用程序一起分发，直到 Microsoft 将其整理出来。

但是，您的（略有不同的）代码可能会创建或引用全局资源，并且在这里可以是碰撞。确定 Windows 变体不使用全局命名的东西，并且这里介绍不同的数据结构？（用于存储标准设置、共享内存、 ...）。由于这种全局性的东西主要依赖于系统——也许你在 Windows 上做了一些你在 Linux 上不做的事情......

【讨论】：