I recall that we had the same problem back in 2010 and solved it. Please describe the ABI differences.

The problems I recall were about linking the C library gpgme against MSVC compiled other binaries.

The problem now is C++ which has a different standard library, different exceptions, different symbol names.

It may somehow work for simple things but at least QGpgME is very complex.
A bad writeup, but the best source I could quickly find:
http://www.mingw.org/wiki/Interoperability_of_Libraries_Created_by_Different_Compiler_Brands

My experience is that it just does not work.

Fwiw the request comes from other people in the KDE community especially for KMymoney. But I see the general need.

Further discussion revealed that the main problem is QtWebengine, which is a requirement of KMail and basically a fully fledged web browser with millions of lines of code. QtWebengine is only supported for MSVC on Windows and a MinGW port is not feasible, so just compiling KMail with MinGW all the way through like I did in the past is no longer an option. :-(

Another build systems does not solve your problem. If you want to support another toolchain, that is fine. But it can as well be done with the current build system. it is a matter of adding a new platform triplet to make sure we are not linking against different libc versions. In fact we can build all our code on a wide range of platforms with very different compilers, so supporting MSVC won't be a problem. Mixing them is a bad idea as can be shown by the usual cross-runtime malloc/free problems.

Just to stress it; I am in favor of allowing builds using other compilers. We allow this on Unix and so we should allow this on Windows as well. We should remember to use different DLL names to make it explicit that a certain DLL is targetting a specific ABI.

Cool and yes, that could also be an option. I was explicitly told by KDE-Windows that this would work for them, too. The problem for me is that I feel comfortable to add a CMake Buildsystem for the Cpp and Qt bindings (maybe Python?). It would be very simple for me, I would not extend it to GPGME core, at least not at first. I could do that on GNU/Linux without having to test an MSVC build.
It will be more effort for me to make autotools work nicely with MSVC. I would have to test that etc.

It's a question how much we want to invest in this and I'm for the pragmatic solution of least effort. And for me that would be CMake support for the language bindings.

High priority and half a year no action....

*bump* to get up in my own todo list.

One issue with this is that Qt Webengine (chrome) cannot be built with mingw. Fixing that would be a major project.

KMail needs Qt Webengine and GpgMEpp. So they have to link somehow and that is the problem described here.

Okay, so the open task is to build gpgme with MSVC in a way that different libnames are used and that we can distribute them along our standard DLLs? Given the easy we can now ssh into Windows there won't be a need to Wine things.