使用来自不同时间/团队编译的同一VS的C++ DLL - ABI兼容性？

Question

重复:我正在寻找相同 Visual-C++版本的库之间的ABI兼容性!

我们希望混合和匹配来自不同团队的一些内部C++ DLL - 在不同时间使用不同的项目文件构建.由于构建时间较长,我们确实希望避免大型单片构建,其中每个团队重新编译另一个团队库的源代码.

当消耗C++的DLL 和C++的接口是相当 清楚 的是,你只能这样做,如果所有的DLL与相同的编译器/ Visual Studio的版本编译.

什么对我来说并不很明显是什么,到底需要是相同的,以获得ABI的兼容性.

• 显然, debug(_DEBUG)和release(NDEBUG)不能混合 - 但是这些链接到不同版本的共享运行时这一事实也很明显.
• 您是否需要完全相同的编译器版本,或者生成的DLL链接到同一共享 C++运行时是否足够- 也就是说,基本上是相同的可再发行组件？(我认为当传递完整的C++对象时静态不会飞)
• 是否存在编译器(和链接器)选项的文档列表,这些选项需要相同才能兼容相同vc ++版本的两个C++ DLL？
  • 例如,是否/O需要相同的开关 - 优化级别是否会影响ABI兼容性？(我很确定不会.)
  • 或者两个版本都必须使用相同的/EH开关？
  • 还是/volatile:ms|iso......？

本质上,我想提出一组(元)数据来与描述它的ABI兼容性的Visual-C++ DLL相关联.

如果存在差异,我现在只关注VS2015.

Answer 1

最近几天我一直在思考这个问题，我所做的就是尝试看看是否存在一些用例，开发人员已经需要对其 C++ 构建进行分类以确保二进制文件兼容。

nuget 的 Native Packages就是这样的地方之一。所以我查看了那里的一个包，特别是cpprestsdk：

可下载包中的二进制文件拆分如下：

native\v120\windesktop\msvcstl\dyn\rt-dyn\x64\Release\
        ^      ^         ^      ^    ^     
  VS version   |       not sure |    uses cpp-runtime dynamically
               |               lib itself dynamic (as opposed to static)
    or WinXP or WinApp(WinRT?)
                 

我从这个例子中取出了这个，因为我找不到任何其他文档。我还知道 boost 二进制文件构建目录以类似的方式分隔。

因此，为了获取元数据列表来识别 ABI 兼容性，我可以初步列出以下内容：

• VC版本（即使用的C和CPP运行时库的版本）
  • 这里的一点是，egvc140现在应该足够了 - 考虑到 CRT 的链接方式，版本控制的 CRT 组件的所有可能的错误修复都必须与 ABI 兼容，因此给定的预编译库是使用哪个版本构建的并不重要。
• 纯天然| 托管 (/CLI) | 温特
• CRT 的消耗方式（静态/动态）
• 位数/平台（Win32、x64、ARM 等）
• 发布或调试版本（即我们链接到哪个版本的 CRT）
• 加：_ITERATOR_DEBUG_LEVEL...如果每个人都采用默认值，那么很好，如果项目不这样做，则必须如此声明

此外，我对以下项目的最佳猜测：

• /O一定没关系 - 我们不断地混合和匹配具有不同优化设置的二进制文件 - 具体来说，这甚至适用于同一二进制文件中的目标文件
• /volatile- 由于这是代码生成的事情，我很难想象这会如何破坏 ABI
• /EH- 除了禁用所有异常的选项之外，在这种情况下，您显然无法调用任何抛出的异常，我非常有信心从 ABI 角度来看这是可以保存的：这里可能存在陷阱，但我认为它们实际上不能被归类为 ABI 兼容。（也许一些复杂的回调链可以说是ABI不兼容，不确定）

其他的：

• 默认调用约定 ( /G..) ：我认为当损坏的导出符号和标头声明不匹配时，这会在链接时中断。
• /Zc:wchar_t- 将在链接时中断（它实际上与 ABI 兼容，但符号无法运行。）
• 启用 RTTI ( /GR) - 对此不太确定 - 我从未使用过此禁用功能。