Why should the same compiler as the dynamic library be used for the dependent application?

Question

Recently I had to compile Qt and the instructions clearly mention that my application should be compiled with the same compiler as the one with which I am compiling Qt. Now I don't understand the reason for this and would like to know if this is specific to Qt or a generic C++ thing?

Answer 1

Introduction

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.

Why Different Compilers may not Interoperate

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
• One compiler offers 3200 different ABIs according to this page: http://www.boost.org/libs/config/config.htm#source
• According to Stroustrup (ARM, 7.2.1c, page 122):

If two C++ implementations for the same system use different calling sequences, or in other ways are not link compatible, it would be unwise to use identical encodings of type signatures.

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:--

• The simple name mangling issue which it may be possible to circumvent with an explicit .def file.
• Different structure alignment issues which need the correct compiler options (-mms-bitfields, ...).
• A fundamental conflict of underlying exception and memory models:--

A new/delete or malloc/free in a MSVC DLL will not co-operate with a Cygwin newlib new/delete or malloc/free. One cannot free space which was allocated in a function using a different new/malloc at all.

An exception raised by an MSVC DLL will not be caught by a Cygwin executable, and vice versa.

The slow GNU SJLJ exception model, (used in GCC-3.x and earlier), is compatible with the MSVC++ model, but the new DWARF2 model, (which will be used by GCC-4.x), will be incompatible.

The canonical source can be found here.