[Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)
Kai.Koehne at qt.io
Thu Aug 22 07:47:26 CEST 2019
> Anyway, my ultimate goal is to create and distribute my Qt apps the same
> way as Qt's installation program (you can tell I really admire that
> program a lot :-)
> i.e. link *everything* statically and build myself a ~ 20 MB humongous
> .exe file (which only needs msvcrt.dll). And that kind of linking,
> Microsoft has never supported nor allowed it.
I'm pretty sure the Qt Installer / MaintenanceTool is actually built with MSVC 🙂
Microsoft supports linking in a static version of the visual studio runtime library by the /MT compiler flag. Qt will automatically do this for you if you configure it with -static-runtime .
From: Development <development-bounces at qt-project.org> on behalf of Henry Skoglund <henry at tungware.se>
Sent: Wednesday, August 21, 2019 9:36 PM
To: Elvis Stansvik <elvstone at gmail.com>
Cc: Qt development mailing list <development at qt-project.org>
Subject: Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)
Yes, I also used app-local deployment, problem is that Microsoft has not
committed 100% to allow it (as far as I know), instead they have a
seesaw approach, saying "you can temporarily use app-local deployment but.."
Anyway, my ultimate goal is to create and distribute my Qt apps the same
way as Qt's installation program (you can tell I really admire that
program a lot :-)
i.e. link *everything* statically and build myself a ~ 20 MB humongous
.exe file (which only needs msvcrt.dll). And that kind of linking,
Microsoft has never supported nor allowed it.
On 2019-08-21 21:22, Elvis Stansvik wrote:
> Den ons 21 aug. 2019 kl 20:52 skrev Henry Skoglund <henry at tungware.se>:
>> Please, don't drop MinGW, it's in my meaning the best compiler on Windows.
>> I've switched from VS to MinGW, the #1 reason: I can distribute an .exe
>> file which is runnable directly on the user's desktop (no installation).
>> This is *verboten* when using VS, you have to send along the
>> distribution dlls (ucrtbase.dll etc.) and install them.
> Why not just ship those DLLs? I wouldn't call that "verboten"
> (forbidden), just a bit more to do for deployment.
> We do app-local deployment (putting the DLLs next to our application),
> which is still supported, and makes it possible for us to deliver a
> portable ZIP in addition to an installer. You don't have to go the
> route of launching the redistributables installer.
> To make it less inconvenient we use CMake's
> InstallRequiredSystemLibraries module along with setting
> CMAKE_INSTALL_UCRT_LIBRARIES to make sure the Universal CRT DLLs are
> also bundled.
>> Also, big wheels like Qt's installer program (MaintenanceTool.exe) have
>> also switched from using Visual Studio to MinGW. I believe for the same
>> reason as mine above, except MaintenanceTool.exe didn't include any VS
>> .dlls, so on early Windows 10 versions, MaintenanceTool.exe failed to
>> start, because no VS2015 runtime was installed.
>> Nowadays MaintenanceTool.exe only requires the 32-bit MSVCRT.DLL to be
>> present, and tbat .dll always gonna be there (just like the VB6 runtime
>> This is one of the few places where Windows still shines: Qt's OOBE on
>> Windows. On that platform, you don't need any chmod +x or waiting for a
>> .dmg to unpack, just double-click on the .exe file.
>> Rgrds Henry
>> On 2019-08-21 20:35, Mathias Hasselmann wrote:
>>> Am 21.08.2019 um 19:38 schrieb Thiago Macieira:
>>>> PPS: can we drop MinGW support in Qt 6?
>>> What alternative do you propse?
>>> Development mailing list
>>> Development at qt-project.org
>> Development mailing list
>> Development at qt-project.org
Development mailing list
Development at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development