[Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)
elvstone at gmail.com
Wed Aug 21 21:54:21 CEST 2019
Den ons 21 aug. 2019 kl 21:36 skrev Henry Skoglund <henry at tungware.se>:
> 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.
Alright, yes, your argument (and Kyle's) make sense I guess. I was
mostly speaking from a practicality perspective (that deployment is
really not that awkward with the right tools).
I know that Microsoft once said it would no longer support app-local
deployment of the Universal CRT, but then changed their mind back in
2015 (see the bullet point 6 in the list at
I don't know if they've changed their mind again, which I think would
be required to really call it a seesaw approach :)
But yea, I too prefer the simplicity of an MIT licensed compiler to
> 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
More information about the Development