Mixing compilers

Gilles Caulier caulier.gilles at gmail.com
Sun Jun 23 13:27:49 BST 2019


Hi,

This is an interesting topic : mixing object compiled with MinGW and MSVC.

In my office, where is maintain a huge framework mixing C and C++ API, the
MSVC support is a nightmare. 80% of the code is compiled for Linux Centos
6/7, and the rest under Windows. We have a CI compiling all the API and
client code which take around 5 hours to build late on night.

Windows still required in my office due to use proprietary drive for device
cards. The provided object are all compiled with MSVC. And working with
Windows is just a waste of time, as it's slow to compile and hack. The team
knowledge is mostly based on Linux and Windows is really an handicap. But
we survive with it.

Few year ago i back ported in my office my huge experience to cross compile
whole digiKam code with MinGW using MXE project (this is a jewel
environment). typically, compiling is not a problem and resolving
dependencies work as expected. The problem is the linking stage between
MinGW objects and MSVC objects.

This is my feedback :

- linking C API between both compiler work well.
- linking C++ API between both compiler is just the hell : MSVC object
fingerprints is different than MinGW and resolving MSVC object do not work.
There are some experiment to modify binary MSVC objects as MinGW but i
considerate this stage very dangerous.

So after a long experiment with students working on this project, we left
the idea to cross compile the framework used in my office. With Linux, we
use GCC, under Windows only MSVC.

There are perhaps a solution to use clang (provided with Visual C++ 2019),
but i never tried this compiler in this situation.

About your problem of WebEngine which cannot be compiled with MinGW, the
problem is know, and Qt bug has a report about this topic. The problem come
from Google team which do not support this compiler with internal engine
code. A possible solution again to cross compile QtWebEngine for Windows
under Linux will be to use Clang instead GCC.

https://bugreports.qt.io/browse/QTBUG-42725

If you have a solution to mix C++ symbols with MinGW and MSVC, it will be
interesting to have another feedbacks.

Best

Gilles Caulier

Le dim. 23 juin 2019 à 10:40, Thomas Friedrichsmeier <
thomas.friedrichsmeier at ruhr-uni-bochum.de> a écrit :

> Hi!
>
> I'll try to break my earlier question about building rkward frontend /
> backend with different compilers into (hopefully) more managable
> chunks. The basic idea is still that we might build our frontend
> process using MSVC (and will be able to use QWebEngine), and the
> backend process using MinGW (in order to solve compatibility
> nightmares). Questions:
>
> 1. I assume it is still correct that craft does not support multiple
> compilers in one installation, and there are no plans to add anything
> the like.
>
> My plan then would have to be along the lines to build the backend,
> alone, on a MinGW craft, and the frontend, on an MSVC craft. Then on
> the MSVC craft, I would additionally fetch the MinGW-built backend
> binary, somehow. So questions:
>
> 2. Can a single craft recipe produce two separate artifacts (frontend /
> backend), or will I need separate recipes?
>
> 3. Can a single recipe be source-compiled on one compiler, but binary
> on another? Or will I need to split the backend package, further, into
> a source recipe and a binary recipe?
>
> 4. (How) can I install a binary package from the binary factory itself?
>
> Regards
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20190623/f2728c0b/attachment.html>


More information about the Kde-windows mailing list