[Mingw-users] Binary compatibility and name mangling [Was: mingw comes with cygwin?]

[Greg C. <chi...@mi...>]

Nathan Fisher wrote:
> 
> On Thu, 2004-04-29 at 15:34, Stephen Ray wrote:
> > The FAQ says you can, with gcc, produce a dll usable with MSVC. It doesn't
> > say anything about C++ code.
> 
>         The incompatibility is primarily caused by differences in the way class
> methods are mangled in the symbol table.

That's the proximate cause. Sometimes people wonder why compiler
writers don't just use the same name-mangling scheme. That would
remove the proximate cause, but unveil the ultimate cause, which
is that there are lots of implementation-defined details. 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

Stroustrup wrote (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.

> The only way I can see using
> GCC C++ DLL objects in a MSVC project would be to also include C style
> functions in the GCC DLL to call the associated methods. Which
> essentially means you'd never be able to directly access the public
> methods of the object.
> 
> So given the following function.
> 
> class Foo
> {
>         public:
>                 virtual void print( );
> };
> 
> You'd have to include something similar to the function below in your
> GCC based DLL.

You probably intend 'extern "C"' here:

> void Foo_print( void * aFoo )
> {
>         (Foo*)aFoo->print( );
> }

Here's a discussion of a more involved technique:

  http://aegisknight.org/cppinterface.html