c++ - 为什么依赖的应用程序要使用与动态库相同的编译器？

Question

最近我不得不编译 Qt，说明中清楚地提到我的应用程序应该使用与我编译 Qt 时使用的相同的编译器进行编译。 现在我不明白这是为什么，想知道这是特定于 Qt 还是通用 C++ 的东西？

Answer 1

简介

Object files and static libraries created with different compilers, or even with significantly different releases of the same compiler, often cannot be linked together. This issue is not specific to MinGW: many other compilers are mutually incompatible. Build everything from source with the same version of the same compiler if you can.

Dll's are slightly different. Sometimes you can link a DLL built with one compiler to an application compiled with another. This works well if the DLL is written in C, even if the application is written in C++. For example, MinGW C++ programs commonly link to the C runtime library provided with Windows. DLLs that are written in C++ work too, as long as you communicate with them only through a C interface declared with extern "C". If you do otherwise, you will probably get linker errors because different compilers mangle C++ names differently.

为什么不同的编译器可能无法互操作

Sometimes people wonder why compiler writers don't just use the same name-mangling scheme. That might make linking succeed, but would most likely give you a program that crashes when you call into the DLL. Real link compatibility requires a common Application Binary Interface, and name-mangling is just one consideration among many. Here's a partial list:--

• http://ou800doc.caldera.com/SDK_porting/binary_cplusplus_compat.html
• 根据此页面，一个编译器提供了 3200 种不同的 ABI:http://www.boost.org/libs/config/config.htm#source
• 根据 Stroustrup(ARM，7.2.1c，第 122 页):

如果同一系统的两个 C++ 实现使用不同的调用序列，或者以其他方式链接不兼容，则使用相同的类型签名编码是不明智的。

Implementors have traditionally used deliberately different name-mangling schemes, figuring it's better to 'just say no' at link time than to make some simple code work and let the issues emerge at run time.

Even though GNU g++ can link MSVC C++ libraries now, and can produce MSVC++ compatible libraries/DLLs, this does not mean that they will be able to work at run-time due to the dynamic nature of C++. Some possible reasons for this are:--

• 可以使用显式 .def 文件规避的简单名称修改问题。
• 不同的结构对齐问题需要正确的编译器选项(-mms-bitfields，...)。
• 底层异常和内存模型的根本冲突:--

MSVC DLL 中的 new/delete 或 malloc/free 不会与 Cygwin newlib new/delete 或 malloc/free 合作。根本无法释放在使用不同的 new/malloc 的函数中分配的空间。

Cygwin 可执行文件不会捕获 MSVC DLL 引发的异常，反之亦然。

缓慢的 GNU SJLJ 异常模型(在 GCC-3.x 和更早版本中使用)与 MSVC++ 模型兼容，但新的 DWARF2 模型(将由 GCC-4.x 使用)将是不兼容。

可以找到规范来源here .