用C交叉编译的二进制兼容性 [英] Crosscompiler Binary compatibility in C

问题描述

我需要验证，我有怀疑的东西。如果共享库文件（.dll）是用C写的，与C99标准编译器编译下。说MinGW的。然后在我的经验是二进制兼容的，因此从任何其他编译器可用。说MS Visual Studio中。我在我的经验说，因为我已经尝试过成功不止一次。但我需要验证，如果这是一个规律。

I need to verify something for which I have doubts. If a shared library ( .dll) is written in C, with the C99 standard and compiled under a compiler. Say MinGw. Then in my experience it is binary compatible and hence useable from any other compiler. Say MS Visual Studio. I say in my experience because I have tried it successfully more than once. But I need to verify if this is a rule.

和另外我想问一下，如果它的确是这样，那么为什么图书馆完全用C写成，如OpenCV的例如没有为每一个不同的操作系统提供编译的二进制文件？我知道，明显的原因是设置所有的编译时间参数，但除此之外再没有吧？

And in addition I would like to ask if it is indeed so, then why libraries written completely in C, like openCV for example don't provide compiled binaries for every different OS? I know that the obvious reason would be to set all the compile-time parameters, but other than that there is none right?

编辑：我添加一个额外的问题，我看的逻辑扩展到原来的。这不是一会怎么走，并创建一个封闭源代码库？由于给源的选项就走出了窗外那里，给二进制文件是唯一的选择。在此情况下尽可能多的体系结构尽可能提供二进制是期望的结果，其中C为用于具有系统和编译器之间的最佳可移植性一个明显的选择。对吧？

I am adding an additional question which I see as a logical extension to the original. Isn't this how one would go and create a closed source library? Since the option of giving source goes out of the window there, giving binaries is the only choice. And in that case providing binaries for as many architectures as possible is the desired result, with C being an obvious choice for having the best portability between systems and compilers. Right?

推荐答案

在在Windows世界C编译器（MSVC和海湾合作委员会/ MinGW的）的特定情况下，你是在二进制兼容性的假设是正确的。人们可以通过GCC编译一个C接口的DLL链接到Visual Studio中的程序。这是路C99项目，如ffmpeg的允许开发人员编写室内用的应用程序的Visual Studio。我们只需要创建LIB.EXE导入库从DLL微软工具链中。反之亦然，使用mingw.org的pexports或更好的MinGW-W64的gendef工具，可以创建一个MSVC产生的DLL中的GCC导入库。

In the specific case of C compilers (MSVC and GCC/MinGW) in the Windows world, you are correct in the assumption of binary compatibility. One can link a C interface DLL compiled by GCC to a program in Visual Studio. This is the way C99 projects like ffmpeg allow developers to write application wiht Visual Studio. One only needs to create the import library with lib.exe found in the Microsoft toolchain from the DLL. Or vice versa, using mingw.org's pexports or better, mingw-w64's gendef tool, one can create a GCC import lib for a MSVC produced DLL.

当你进入C ++接口的世界里，MSVC的ABI和GCC是不同的，不兼容的这种方便的互操作性分解。它可能工作，也可能没有，没有担保是由没有力气是（目前）在改变了正在做。此外，调试信息显然是不同的，直到有人在GCC的是MSVC的调试器兼容（连同GDB的支持，当然）写入调试信息生成器/刻录机。

This handy interoperability breaks down when you enter the C++ interface world, where the ABI of MSVC and GCC is different and incompatible. It may work, it may not, no guarantees are made and no effort is (currently) being done in changing that. Also, debugging info is obviously different, until someone writes a debug information generator/writer in GCC that is compatible to MSVC's debugger (along with gdb support of course).

我不认为C99专门改变任何东西起作用声明或参数方式符号定义的处理，所以应该没有问题就在这里无论是。

I don't think C99 specifically changes anything to function declarations or the way arguments are handled in symbol definitions, so there should be no problem here either.

请注意，作为维杰所述，仍有架构不同，所以不能用一个86的库链接到AMD64库时

Note that as Vijay said, there is still the architecture difference, so a x86 library can't be used when linking to an AMD64 library.

要还回答您关于封闭源代码的二进制文件的其他问题，并分发版本的所有可用的编译器/架构。

To also answer your additional question about closed source binaries and distributing a version for all available compilers/architectures.

这正是你将创建一个开放源码的二进制的方式。除了导入库，这也是非常重要的隐藏从DLL导出，使得DLL本身无用的链接（如果你不希望客户端code到库使用专用的功能，例如见的输出DUMPBIN /出口上的MSOffice DLL，很多隐藏的东西在那里）。可以实现与GCC同样的事情（我相信，从来没有使用过或尝试过），使用像 __的东西属性（隐藏）等...

This is exactly the way you would create a closed source binary. In addition to the import library, it is also very important to hide exports from the DLL, making the DLL itself useless for linking (if you don't want client code to use private functions in the library, see for example the output of dumpbin /exports on a MSOffice DLL, lots of hidden stuff there). You can achieve the same thing with GCC (I believe, never used or tried it) using things like __attribute(hidden) etc...

编译器的一些具体问题：

Some compiler specific points:

1. MSVC带有四个（当然，实际上只有三个新版本剩余）通过/ MT不同的运行时库/ MD和/ LD。在此之上，你就必须提供为Visual Studio（包括Service Pack）的每个版本构建，以确保兼容性。但是，这是封闭源代码的二进制和Windows为你...

1. MSVC comes with four (well, actually only three remaining in newer versions) different runtime libraries through /MT, /MD, and /LD. On top of this, you would have to provide a build for each version of Visual Studio (including Service Packs) to assure compatibility. But that is closed source binary and Windows for you...

GCC不存在这个问题; MinGW的能连到MSVCRT.DLL Windows提供（因为Windows 98），相当于用/ MD（也许也是一个调试库相当于与/ MDD）。但我也有MinGW的（mingw.org和MinGW-W64），它不保证二进制兼容性的两个版本。后者是因为它提供了64位的选项，以及32位较为齐全，并提供了更完整的头/库集（包括DirectX和DDK的很大一部分）。

GCC does not have this problem; MinGW always links to msvcrt.dll provided by Windows (since Windows 98), equivalent with /MD (and maybe also a debug library equivalent with /MDd). But I there are two versions of MinGW (mingw.org and mingw-w64) which do not guarantee binary compatibility. THe latter is more complete as it provides 64-bit options as well as 32-bit, and provides a more complete header/library set (including a substantial part of DirectX and DDK).

这篇关于用C交叉编译的二进制兼容性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！