Interoperability of Libraries Created by Different Compiler Brands

http://www.mingw.org/wiki/MixingCompilersPosted July 22nd, 2009 by keith

• gcc
• interoperability
• libraries
• mixing compilers
• msvc

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.

Circumventing the Issues

The article at http://aegisknight.org/cppinterface.html
describes an advanced technique which may help you to work around the
name-mangling and linking problems; be sure to follow its guidelines
carefully, if you try it.