Compatibility between compilers

[stav]

Hi
i recently ran in to a problem where i couldn't link with a library because it was compiled with msvc and i was using mingw gcc.

I read on mingw's website that the reason some compilers cant interoperate (even if they are targeting the same platform) is because different compilers create different ABIs.

But i dont really understand how thats possible?
They both produce a .lib file right? how can they have different ABIs if they use the same file format?

I don't know the .lib format but im assuming it just conatins a bunch of chunks with function information + an offset into the dll to execute the function, so as long as both compilers follow this specification, shouldn't they both be able to read the .lib file and link with it?


(i know different compilers use different name mangling schemes as well, but on mingw's website it said that the only reason they use different schemes is because of the ABI problem)

[tpb]

The .lib file format has nothing to do with it.

Each compiler has implemented the standard library classes differently. They can even implement virtual call dispatch differently (at least so far as the placement of the virtual function table in the object).

It's these things that need to match up so the function calls work. And they're baked into the functions that are stored inside the library, so it can't be fixed in any reasonable way short of recompiling the code on the new system.

[Cubbi]

function information + an offset into the dll to execute the function, so as long as both compilers follow this specification, shouldn't they both be able to read the .lib file and link with it?

One problem, already mentioned, is that layouts of standard library classes (there are three in existence: Microsoft's, GNU, and LLVM) may be different, and also may change version to version. This is usually solved by "hourglass interfaces", "pimpl", and other such ways of making library entry points ABI-stable.

But for interaction between MSVC and MinGW, there's a bigger problem: you can't call a function whose location you know if your calling convention does not match! For example, on a 64-bit intel target, the first function parameter of integer type goes in the CPU register %rdx in the Microsoft ABI and in CPU register %rdi in Everyone Else's ABI (a long time ago each compiler was on its own, but over time only two ABIs survived for both C and C++)

[jlb]

(i know different compilers use different name mangling schemes as well, but on mingw's website it said that the only reason they use different schemes is because of the ABI problem)

Don't forget "ABI problems" can also happen when using the same compiler when using different versions of that compiler.

If you want to be able to use a library between different compilers you probably should stick with shared/dynamically linked libraries (.so/.dll) instead of statically linked libraries (.lib). Shared libraries are meant to be used by many different compilers and interoperate better between the different compilers.

[helios]

If you want to be able to use a library between different compilers you probably should stick with shared/dynamically linked libraries (.so/.dll) instead of statically linked libraries (.lib). Shared libraries are meant to be used by many different compilers and interoperate better between the different compilers.

No, you're still not supposed to mix and match C++ DLLs/SOs produced by different compilers. And let's not get into the nightmare that is passing pointers to C++ objects across DLL boundaries.

[jlb]

Correct, I don't do a lot of shared libs so I forgot that the only "portable" way to share a C++ lib is with extern "C" littering the landscape with all the limitations of C implied.