[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-windows
Subject: Re: Mixing compilers
From: Gilles Caulier <caulier.gilles () gmail ! com>
Date: 2019-06-23 12:27:49
Message-ID: CAHFG6sGJbyhQRWj2kTh48fpziNwg6DQ0S5N4D2tD2qPU7eGYpw () mail ! gmail ! com
[Download RAW message or body]
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 =C3=A0 10:40, Thomas Friedrichsmeier <
thomas.friedrichsmeier@ruhr-uni-bochum.de> a =C3=A9crit :
> 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
>
[Attachment #3 (text/html)]
<div dir="ltr">Hi,<div><br></div><div>This is an interesting topic : mixing object \
compiled with MinGW and MSVC.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>This is my feedback \
:</div><div><br></div><div>- linking C API between both compiler work \
well.</div><div>- 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.</div><div><br></div><div>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.</div><div><br></div><div>There are perhaps a solution to use clang (provided \
with Visual C++ 2019), but i never tried this compiler in this \
situation.</div><div><br></div><div>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.</div><div><br></div><div><a \
href="https://bugreports.qt.io/browse/QTBUG-42725">https://bugreports.qt.io/browse/QTBUG-42725</a></div><div><br></div><div>If \
you have a solution to mix C++ symbols with MinGW and MSVC, it will be interesting to \
have another feedbacks.</div><div><br></div><div>Best</div><div><br></div><div>Gilles \
Caulier </div></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">Le dim. 23 juin 2019 Ã 10:40, Thomas Friedrichsmeier <<a \
href="mailto:thomas.friedrichsmeier@ruhr-uni-bochum.de">thomas.friedrichsmeier@ruhr-uni-bochum.de</a>> \
a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi!<br> <br>
I'll try to break my earlier question about building rkward frontend /<br>
backend with different compilers into (hopefully) more managable<br>
chunks. The basic idea is still that we might build our frontend<br>
process using MSVC (and will be able to use QWebEngine), and the<br>
backend process using MinGW (in order to solve compatibility<br>
nightmares). Questions:<br>
<br>
1. I assume it is still correct that craft does not support multiple<br>
compilers in one installation, and there are no plans to add anything<br>
the like.<br>
<br>
My plan then would have to be along the lines to build the backend,<br>
alone, on a MinGW craft, and the frontend, on an MSVC craft. Then on<br>
the MSVC craft, I would additionally fetch the MinGW-built backend<br>
binary, somehow. So questions:<br>
<br>
2. Can a single craft recipe produce two separate artifacts (frontend /<br>
backend), or will I need separate recipes?<br>
<br>
3. Can a single recipe be source-compiled on one compiler, but binary<br>
on another? Or will I need to split the backend package, further, into<br>
a source recipe and a binary recipe?<br>
<br>
4. (How) can I install a binary package from the binary factory itself?<br>
<br>
Regards<br>
Thomas<br>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic