Tag: 二进制兼容性

交叉编译器C中的二进制兼容性

我需要validation一些我怀疑的东西。 如果共享库（.dll）是用C语言编写的，那么使用C99标准并在编译器下编译。 说MinGw。 然后根据我的经验，它是二进制兼容的，因此可以从任何其他编译器使用。 说MS Visual Studio。 我根据自己的经验说，因为我不止一次成功地尝试过它。 但我需要validation这是否是一个规则。 另外我想问一下它是否确实如此，那么为什么用C语言完全用C语言编写的库，例如openCV不为每个不同的操作系统提供编译的二进制文件？ 我知道明显的原因是设置所有编译时参数，但除此之外没有正确的吗？ 编辑：我正在添加一个额外的问题，我认为这是原始的逻辑扩展。 这不是一个人如何去创建一个封闭的源库吗？ 由于提供源的选项不在窗口中，因此给出二进制文件是唯一的选择。 在这种情况下，为尽可能多的体系结构提供二进制文件是理想的结果，C是在系统和编译器之间具有最佳可移植性的明显选择。 对？

库ABI Visual Studio版本之间的兼容性

我有两个场景。 假设我有3个导出C ++符号的共享库，每个库都使用VS7.1，VS8和VS9构建。 我在VS9中编译了所有3个。 出于某种原因，这是有效的。 我不需要在VS9中为VS9链接器重新编译前两个库，以便成功找到符号并链接它们。 现在，如果我有一个只使用C语法（extern“C”）导出符号的库，这是一样的吗？ 我听说有人说ABI for C是标准化的，所以在某种程度上保证你可以在所有版本的Visual Studio中使用Visual Studio 8中编译的C库。 基本上，所有这些事情的结合令人困惑。 我不确定在不同版本的Visual Studio之间链接C ++和基于C的共享库（使用相应的导入库）之间有什么保证。 我想听听关于任何其他版本的Visual Studio上C 和 C ++导入或静态库的向前/向后兼容性的一致意见。 这对我来说是因为我使用的闭源库是在Visual Studio .NET 2003（VS7.1）中编译的。 我的团队认为这将我们锁定到VS 7.1编译器，但是我已经在VS8和VS9中测试了这些库，甚至是VS2010，它们链接得很好。 但是，我不确定这个内在的危险。 请注意，所讨论的库具有C变体和C ++变体。 基本上，C变量是标准C导出，而C ++库是C库和导出类的抽象。