How to link to VS2008 generated .libs from g++

Question

I am trying to build a dll using mingw g++ under cygwin.

I have .h files that refer to objects exported by a .dll that was build using MS Visual Studio 2008. I link to the .lib generated with that .dll.

When I run g++ I get lots of errors like this

/cygdrive/c/dev/blox/ulfx/ulfx/JavaInterface.cpp:206: undefined reference to `__imp___ZNK18DLLSafeDoubleArray4sizeEv'

The .dll that I want to link to exposes a function named

?size@DLLSafeDoubleArray@@QBEIXZ

And I assume that the problem here is that the g++ name mangling is incompatible with the VS2008 name mangling.

Is there a way I can force g++ to use a compatible mangling ?

I do not have any version of Visual Studio installed on my machine.

Answer 1

G'day,

Not sure if this is going to be possible as there is too much that can vary between compilers from different vendors apart from just the name mangling. Things such as:

1. this handling,
2. layout and contents of v-tables,
3. class layout,
4. parameter sequence,
5. register handling,
6. return value handling,
7. etc.

I'd be interested to see if it was possible though.

Answer 2

Maybe this page helps:

http://www.mingw.org/wiki/MSVC%5Fand%5FMinGW%5FDLLs

I did manage to do something once but it was just a prototype which I abandoned when I found a library doing what I wanted. I did follow their instructions though, but I was producing the dll myself.

Answer 3

I agree with Rob Wells comment, there are a lot of things in C++ that may break.

Something which should be easier, safer, and possible would be to use plain C functions, as the main thing to worry about there is the calling convention and potentially packing and alignment of structs.

Answer 4

Better way is to recompile dll with g++. If it is possible.

Answer 5

Object code produced by different C++ compilers is not link compatible.

This is done on purpose: compilers use different ABI, and if the name maingling didn't prevent you from linking, you'd now be wondering/debugging why the simplest operations are causing your executable to crash.

You should be grateful that the different name mangling scheme spared you that debugging effort.