使用来自在不同时间/团队编译的同一VS的C ++ DLL-ABI兼容性吗? [英] Use C++ DLLs from the same VS compiled at different times/teams - ABI compatibility?

问题描述

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

To repeat: I'm looking for ABI compatibility between libraries of the same Visual-C++ version!

我们想混合使用来自不同团队的一些内部C ++ DLL，这些DLL是在不同的时间使用不同的项目文件构建的.由于构建时间长，我们完全希望避免大型的整体构建，因为每个团队都将重新编译另一个团队的库的源代码.

We want to mix and match some internal C++ DLLs from different teams - built at different times with different project files. Because of long build times, we exactly want to avoid large monolithic builds where each team re-compiles the source code of another team's library.

使用具有C ++接口的C ++ DLL 时，它是相当 清除

When consuming C++ DLLs with C++ interfaces it is rather clear that you only can do this if all DLLs are compiled with the same compiler / Visual Studio version.

对我来说，不太明显的是 ，为了获得ABI兼容性，它们必须完全相同.

What is not readily apparent to me is what, exactly needs to be the same to get ABI compatibility.

• 很明显调试(_DEBUG)和发行版(NDEBUG)不能混合使用-但是从这些链接到共享运行时的不同版本这一事实也很明显.
• 您是否需要完全相同的 compiler 版本，或者生成的DLL链接到相同的 shared C ++运行时是否就足够了?也就是说，基本上是相同的版本可再分发? (我认为在传递完整的C ++对象时，static不会飞行)
• 是否有编译器(和链接器)选项是否需要相同才能使同一vc ++版本的两个C ++ DLL兼容?
  • 例如，是否需要相同的/O开关-优化级别是否会影响ABI兼容性? (我敢肯定不会.)
  • 还是两个版本都必须使用相同的 /EH开关?
  • 还是 /volatile:ms|iso ...?
  • Obviously debug (_DEBUG) and release (NDEBUG) cannot be mixed -- but that's also apparent from the fact that these link to different versions of the shared runtime.
  • Do you need the exact same compiler version, or is it sufficient that the resulting DLL links to the same shared C++ runtime -- that is, basically to the same redistributable? (I think static doesn't fly when passing full C++ objects around)
  • Is there a documented list of compiler (and linker) options that need to be the same for two C++ DLLs of the same vc++ version to be compatible?
    • For example, is the same /O switch necessary - does the optimization level affect ABI compatibility´? (I'm pretty sure not.)
    • Or do both version have to use the same /EH switch?
    • Or /volatile:ms|iso ... ?

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

    如果存在差异，我目前仅关注VS2015.

    If differences exist, my focus is on VS2015 only at the moment.

    推荐答案

    在过去的几天里一直在考虑这一点，而我所做的就是尝试查看是否存在一些用例，在这些用例中，开发人员已经需要对其进行分类. C ++构建可确保二进制文件兼容.

    Have been thinking this through the last days, and what I did do was to try to see if some use-cases exists where devs have already needed to categorize their C++ build to make sure binaries are compatible.

    一个这样的地方是来自nuget的本地软件包.因此，我在那里查看了一个软件包，特别是 cpprestsdk :

    One such place is the Native Packages from nuget. So I looked at one package there, specifically the cpprestsdk:

    我从本示例中删除了此内容，因为找不到其他文档.我也知道，boost二进制文件的构建目录以类似的方式分开.

    I pulled this out from this example, because I couldn't find any other docs. I also know that the boost binaries build directory is separated in a similar way.

    因此，要获取元数据列表以标识ABI兼容性，我可以初步列出以下内容:

    So, to get to a list of meta data to identify the ABI compatibility, I can preliminarily list the following:

    • VC版本(即，使用的C和CPP运行时库的版本)
      • 这里的重点是vc140现在应该足够了-鉴于如何链接CRT，无论如何，对版本化CRT组件的所有可能的错误修正都必须与ABI兼容，因此，给定的预编译库所使用的版本与该版本无关.
      • VC version (that is, the version of the C and CPP runtime libraries used)
        • one point here is that e.g. vc140 should be enough nowadays - given how the CRT is linked in, all possible bugfixes to the versioned CRT components must be ABI compatible anyway, so it shouldn't matter which version a given precompiled library was built with.

        我对以下项目的最佳猜测:

        • /O没关系-我们不断将二进制文件与不同的优化设置进行混合和匹配-特别是，这甚至适用于同一二进制文件中的目标文件
        • /volatile-由于这是代码生成的东西，因此我很难想象这如何破坏ABI
        • /EH-除了禁用所有异常的选项外，在这种情况下，您显然不能调用任何引发的异常，我非常有信心从ABI的角度来看这是可以避免的:这里可能存在陷阱，但是我认为他们不能真正归类为ABI兼容. (也许不确定某些复杂的回调链是否与ABI不兼容)
        • /O must not matter - we constantly mix&match binaries with different optimization settings - specifically, this is even working for object files within the same binary
        • /volatile - since this is a code-gen thing, I have a hard time imagining how this could break an ABI
        • /EH - except for the option to disable all exception, in which case you obviously can't call anything that throws, I'm pretty confident this is save from an ABI perspective: There are possible pitfalls here, but I think they can't really be categorized into ABI compat. (Maybe some complex callback chains could be said to be ABI incompatible, not sure)

        其他:

        • 默认调用约定(/G..):我认为在链接时间，当错误的导出符号和标头声明不匹配时，这会中断.
        • /Zc:wchar_t-会在链接时中断(它实际上是ABI兼容的，但是符号不能连贯.)
        • 启用RTTI(/GR)-不太确定'启用此功能-我从未使用过此禁用功能.
        • Default calling convention (/G..) : I think this would break at link time, when mangled export symbols and header declarations don't match up.
        • /Zc:wchar_t - will break at link time (It's actually ABI compatible, but the symbols won't macth.)
        • Enable RTTI (/GR) - not too sure 'bout this one - I never have worked with this disabled.

        这篇关于使用来自在不同时间/团队编译的同一VS的C ++ DLL-ABI兼容性吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！