[Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

[Kai Köhne]

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

Kai
________________________________
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.
>
> Elvis
>
>> 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
>> etc.)
>>
>> 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
>>> https://lists.qt-project.org/listinfo/development
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> https://lists.qt-project.org/listinfo/development

_______________________________________________
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190822/ab0dd353/attachment.html>