llvm-gcc 和 clang 二进制文件与 gcc 兼容吗？ - 特别是 Windows 上的 mingw gcc
如果我使用 llvm-gcc 构建静态库，然后将其与使用 mingw gcc 编译的程序链接，结果会起作用吗？
对于 llvm-gcc、clang 和普通 gcc 的其他组合也是如此。我对 Linux（当然使用普通的非 mingw gcc）和其他平台上的工作原理很感兴趣，但重点是 Windows。
我也对所有语言感兴趣，但重点关注 C 和 C++ - 显然 clang 不支持 Fortran 等，但我相信 llvm-gcc 可以。
我假设它们都使用 ELF 文件格式，但是调用约定、虚拟表布局等呢？
If I build a static library with llvm-gcc, then link it with a program compiled using mingw gcc, will the result work?
The same for other combinations of llvm-gcc, clang and normal gcc. I'm interested in how this works out on Linux (using normal non-mingw gcc, of course) and other platforms as well, but the emphasis is on Windows.
I'm also interested in all languages, but with a strong emphasis on C and C++ - obviously clang doesn't support Fortran etc, but I believe llvm-gcc does.
I assume they all use the ELF file format, but what about call conventions, virtual table layouts etc?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
是的，对于 C 代码，Clang 和 GCC 是兼容的（事实上，它们都使用 GNU 工具链进行链接。）您只需确保告诉 clang 创建编译对象而不是中间位码对象。 C ABI 定义良好，因此唯一的问题是存储格式。
C++ 根本不能在编译器之间移植；不同的编译器使用不同的虚拟表调用、构造函数、销毁、名称修改、模板实现等。通常，您应该假设来自一个 C++ 编译器的对象不能与另一个编译器一起工作。
不过，是的，在撰写本文时，Clang++ 也能够使用 GCC/C++ 编译的库；我最近设置了一个装置，使用 G++ 的标准运行时库使用 clang 编译 C++ 程序，并且它编译+链接得很好。
Yes, for C code Clang and GCC are compatible (they both use the GNU Toolchain for linking, in fact.) You just have to make sure that you tell clang to create compiled objects and not intermediate bitcode objects. C ABI is well-defined, so the only issue is storage format.
C++ is not portable between compilers in the slightest; different compilers use different virtual table calls, constructors, destruction, name mangling, template implementations, etc. As a rule you should assume objects from one C++ compiler will not work with another.
However yes, at the time of writing Clang++ is able to use GCC/C++ compiled libraries as well; I recently set up a rig to compile C++ programs with clang using G++'s standard runtime library and it compiles+links just fine.
我不知道答案，但是此演示文稿中的第 10 张幻灯片似乎暗示 llvmgcc 生成的“.o”文件包含 LLVM 字节码 (.bc)，而不是通常的特定于目标的目标代码，因此可以进行链接时优化。然而，LLVM 链接器应该能够将 LLVM 代码与“普通”GCC 生成的代码链接起来，如下一张幻灯片所示“链接到本机 .o 文件和库”。
LLVM 是一个 Linux 工具，我有时发现 Linux 编译器在 Windows 上不能正常工作。我很好奇你是否能让它发挥作用。
I don't know the answer, but slide 10 in this presentation seems to imply that the ".o" files produced by llvmgcc contain LLVM bytecode (.bc) instead of the usual target-specific object code, so that link-time optimization is possible. However, the LLVM linker should be able to link LLVM code with code produced by "normal" GCC, as the next slide says "link in native .o files and libraries here".
LLVM is a Linux tool, I have sometimes found that Linux compilers don't work quite right on Windows. I would be curious whether you get it to work or not.
当通过 ld 链接 clang 的 .o 文件时，我使用 -m i386pep 。 llvm 致力于与 gcc 集成可以在 http://dragonegg.llvm.org/ 上公开看到，因此它非常直观猜测 llvm 系列将极大地与 gcc 工具链交叉兼容。
I use -m i386pep when linking clang's .o files by ld. llvm's devotion to integrating with gcc is seen openly at http://dragonegg.llvm.org/ so its very intuitive to guess llvm family will greatly be cross-compatible with gcc tool-chain.
抱歉 - 我休息后回到 llvm，除了教程之外，我从来没有做过更多的事情。第一次，我在努力让 LLVM 2.6 在 MinGW GCC 上构建之后有点精疲力尽 - 幸运的是 LLVM 2.7 这不是问题。
今天再次浏览该教程，我注意到在教程的第 5 章中不仅明确声明 LLVM 使用平台的 ABI（应用程序二进制接口），而且教程编译器依赖于此来允许访问外部函数，例如正弦和余弦。
不过，我仍然不知道兼容的 ABI 是否扩展到 C++。这不是调用约定的问题，而是名称修改、结构布局和虚函数表布局的问题。
对于大多数事情来说，能够进行 C 函数调用就足够了，但还有一些我关心 C++ 的问题。
Sorry - I was coming back to llvm after a break, and have never done much more than the tutorial. First time around, I kind of burned out after the struggle getting LLVM 2.6 to build on MinGW GCC - thankfully not a problem with LLVM 2.7.
Going through the tutorial again today I noticed in Chapter 5 of the tutorial not only a clear statement that LLVM uses the ABI (Application Binary Interface) of the platform, but also that the tutorial compiler depends on this to allow access to external functions such as sin and cos.
I still don't know whether the compatible ABI extends to C++, though. That's not an issue of call conventions so much as name mangling, struct layout and vtable layout.
Being able to make C function calls is enough for most things, there's still a few issues where I care about C++.
希望他们修复了它，但我避免使用 llvm-gcc，因为我（也）使用 llvm 作为交叉编译器，当你在 64 位机器上使用 llvm-gcc -m32 时，-m32 会被忽略，你会得到 64 位整数，它必须是在你的 32 位目标机器上伪造。 Clang 和 gcc 都没有这个 bug。而且我使用 clang 的次数越多，我就越喜欢。至于你的直接问题，不知道，理论上现在的目标已经众所周知或使用了调用约定。你可能希望 gcc 和 llvm 都符合相同的要求，但你永远不知道。找出这个问题的最简单方法是编写几个简单的函数，使用这两个工具集进行编译和反汇编，并查看它们如何将操作数传递给函数。
Hopefully they fixed it but I avoid llvm-gcc because I (also) use llvm as a cross compiler and when you use llvm-gcc -m32 on a 64 bit machine the -m32 is ignored and you get 64 bit ints which have to be faked on your 32 bit target machine. Clang does not have that bug nor does gcc. Also the more I use clang the more I like. As to your direct question, dont know, in theory these days targets have well known or used calling conventions. And you would hope both gcc and llvm conform to the same but you never know. the simplest way to find this out is to write a couple of simple functions, compile and disassemble using both tool sets and see how they pass operands to the functions.