> 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 <[email protected]> on behalf of Henry Skoglund <[email protected]> Sent: Wednesday, August 21, 2019 9:36 PM To: Elvis Stansvik <[email protected]> Cc: Qt development mailing list <[email protected]> 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 <[email protected]>: >> 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 >>> [email protected] >>> https://lists.qt-project.org/listinfo/development >> _______________________________________________ >> Development mailing list >> [email protected] >> https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
