Thanks for all responses.
Compiler ABI's are incompatible in general, but there was a nice exception
in the windows world with interfaces (ie classes with only pure virtual
functions) which were indeed working under most windows compilers, as the
COM/RPC had somewhat established a standard.
With
2015-06-17 18:21 GMT+02:00 lh_mouse :
> g++ and clang++ use Itanium ABI while MSVC uses some M$ specific,
> unpublished ABI. Hence it is not surprising that they are incompatible with
> each other.
>
>
Clang actually aspires to use MSVC's ABI on Windows, and they're close, if
not already in a usef
g++ and clang++ use Itanium ABI while MSVC uses some M$ specific, unpublished
ABI. Hence it is not surprising that they are incompatible with each other.
--
Best regards,
lh_mouse
2015-06-18
--
On Wed, Jun 17, 2015 at 1:08 PM, Ruben Van Boxem
wrote:
>
>>
> This is most likely an ABI issue yes, because you are relying on the
> binary interface of the app and dll to be the same (i.e. the objects are
> assumed to have the same memory layout and alignment and padding and
> whatnot). Unfortu
Yes, you can say it's an ABI issue. There are generally no C++ ABI
provisions for inter-compiler (complex) object passing. You have only
moderate access to influence name mangling (via extern "C" { } constructs)
and calling convention (stdcall and friends), but inheritance has other
requirements (V
2015-06-17 17:44 GMT+02:00 Etienne Sandré-Chardonnal :
> Dear all,
>
> I have a plugin system in my app based on interfaces (classes with only
> pure virtual functions). The app is compiled with mingw-w64 4.9.2 and works
> well with plugin dlls compiled with the same compiler.
>
> Now I am trying
Dear all,
I have a plugin system in my app based on interfaces (classes with only
pure virtual functions). The app is compiled with mingw-w64 4.9.2 and works
well with plugin dlls compiled with the same compiler.
Now I am trying to support MSVC compiled plugins.
This works partially : the app ca
