Make it possible to combine GpgMEpp and QGpgme with MSVC compiled binaries
Open, HighPublic

Description

This is not about cmake vs. autotools. This is about C++ ABI problems between compilers. Notably MinGW/GCC and MSVC.

The Problem is that in the past GpgMEpp had a CMake build system. This allowed it to be compiled with MSVC and linked against a MinGW compiled GPGME from a binary dev package.

Since switching to autotools we no longer have the option.
This hinders adoption for people who require (for whatever reason) to combine GpgME++ and QGpgME with other Code compiled with MSVC. This was possible in the past and no longer is possible.

I would accept having a parallel Buildsystem for the C++ Language Bindings (Libraries QGpgME and GPGME++). And for CMake I would be willing to maintain this in parallel.

aheinecke created this task.Aug 1 2017, 6:04 PM
werner added a subscriber: werner.Aug 1 2017, 6:21 PM

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.

aheinecke claimed this task.EditedMon, Dec 3, 4:35 PM

I think that is something I want to grapple with next year. The maintainer of KDE 4 windows noted that they currently rely on the patches from:

https://github.com/LibreOffice/core/tree/master/external/gpgmepp

aheinecke raised the priority of this task from Wishlist to High.EditedMon, Dec 3, 4:44 PM

I give this high priority. This blocks for years that the KDE-Windows initiative provides a way to install the very good crypto MUA KMail on windows. They rely on MSVC (you can say that this is bad, but it is a fact of life). As a former member of that community I am a bit ashamed that I made it harder / impossible for them to build KMail with MSVC because I've moved it to GPGME proper.

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. :-(

werner added a comment.Tue, Dec 4, 8:46 AM

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.

werner added a comment.Tue, Dec 4, 8:50 AM

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.