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

[Ray Donnelly]

On Thu, 22 Aug 2019, 00:01 Thiago Macieira, 
wrote:

> On Wednesday, 21 August 2019 13:39:55 PDT Kai Pastor, DG0YT wrote:
> > Note that this is the MSYS subsystem, not a MinGW subsystem of MSYS2.
> > For building Windows applications, you use a MinGW subsystem, and there
> > is no msys-2.0.dll.
>
> That's just MinGW, albeit the build from MSYS2. If that's what was meant,
> I'm
> all for it. After the upgrade I've just run, I have GCC 9.2, which is
> great.
>

It is not MinGW,v it is a mingw-w64 based, developer focused build system.
The POSIX software we provide exists only to support this goal. To be clear
we refuse to add packages to the msys2 subsystem package set if they are
not either in support of building native software or in support of making
life easier for developers of the same.

We (along with conda-forge though both independently) are also leading the
charge to get clang into a working state on windows.

You can see the patches we apply and it recipe at
https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-qt5

I find it depressing quite frankly that you know so little about it given
your position. MSYS2 grew out of the old QtBuilds and mingw-builds projects
(same initial developers). We also decided from the beginning to use dw2
exceptions based on your recommendation. This was many years ago. Try it
you might like it. The initial runtime update thing is unfortunate, we link
our pacman as statically as we can but it's not possible to statically link
the runtime. MSYS2 has also been adopted as the upstream env for Git for
Windows so mostly everyone using git on windows is running MSYS2 software
even if they do not know it. Also most of the old game system and computer
emulation world are based on MSYS2. I could do on but I will not. It is the
greatest gift to software packaging on windows yet to be created IMNSHO (I
am very proud of our success here) though for scientific computing
conda-forge is often more appropriate. We also produce builds - MSVC based,
but considering clang as the compiler in the future - of qt at conda-forge
(I help maintain the recipes). Those patches can be found at
https://github.com/conda-forge/qt-feedstock/tree/master/recipe

I would love to upstream what I can from these endeavors but my time is
short (in a very real, serious sense). I'd love to work closely with a few
core developers to unload this patch burden from both before I cannot
anymore.

>
> But I had understood the proposal as linking to MSYS2 libraries.
>

You should always assume that native software is being discussed when
people mention MSYS2 in this way.


> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

On Wednesday, 21 August 2019 23:37:35 PDT Henry Skoglund wrote:
> Aha, sorry for my ignorance! Yes, Thiago wrote about the -static-runtime
> option yesterday, I have to try it out (perhaps also wait for that
> update 16.0 to MSVC2017, when it supposedly has less static-flavored bugs)

The 16.0 update to MSVC 2017 has already been released, but got a new name: 
MSVC 2019.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Henry Skoglund]

Aha, sorry for my ignorance! Yes, Thiago wrote about the -static-runtime 
option yesterday, I have to try it out (perhaps also wait for that 
update 16.0 to MSVC2017, when it supposedly has less static-flavored bugs)


Rgrds Henry
P.S. Recently I uninstalled Visual Studio from all my machines, guess 
it's time to say:
"Come back Microsoft, everything is forgiven, your linking ability is 
second to none"



On 2019-08-22 07:47, Kai Köhne wrote:

> 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  on behalf of 
Henry Skoglund 

*Sent:* Wednesday, August 21, 2019 9:36 PM
*To:* Elvis Stansvik 
*Cc:* Qt development mailing list 
*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 :
>> 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@qt-project.org
>>> https://lists.qt-project.org/listinfo/development
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Kevin Kofler]

Thiago Macieira wrote:
> The same code compiled with the GCC/MinGW 8.2 that I have on my openSUSE
> system. (I'd have tested GCC/MinGW on Windows, but the terminal and/or
> bash refuse to paste text) I don't know when GCC implemented the
> functionality.

Looks like it already works with 7.3.0:
[kevin@desktop64 ~]$ cat >mingw-tls-test.cc < struct S { S(); ~S(); };
> 
> void f()
> {
> thread_local S s;
> }
> EOF
[kevin@desktop64 ~]$ x86_64-w64-mingw32-g++ --version
x86_64-w64-mingw32-g++ (GCC) 7.3.0 20180125 (Fedora MinGW 7.3.0-1.fc28)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[kevin@desktop64 ~]$ x86_64-w64-mingw32-g++ -O2 -c mingw-tls-test.cc
[kevin@desktop64 ~]$ ls -l mingw-tls-test.o
-rw-rw-r-- 1 kevin kevin 1323 22. Aug 01:56 mingw-tls-test.o

(Obviously, this does not link, because there are no implementations of the 
constructor and destructor and no main function.)

In any case, it is good news that this seems to be solved already, because:

> So let me instead change my request:
> Can we require GCC 8 for MinGW for Qt 5.15?

This is a much more reasonable request than the original one.

For what it's worth, the oldest still supported Fedora release (Fedora 29) 
has a cross-MinGW-w64 GCC 8.3.0. (My machine with 7.3.0 is out of date and 
scheduled (by me) to be upgraded tomorrow, so you're lucky that I was still 
able to easily test that version today. ;-) ) So requiring GCC 8 should be 
fine from our side (even though it looks like GCC 7 would be enough, maybe 
even an earlier version).

On the other hand, dropping MinGW support entirely would be a really bad 
idea IMHO, considering that Visual C++ does not support cross-compilation 
and also that there seems to be no non-buggy version of Visual C++ available 
at this time. (You want to get rid of VC++2015 for being unsupported and 
VC++2017 for being buggy, yet also cannot recommend VC++2019 due to new code 
generation bugs.) For me, it would mean that I would no longer be able to 
build my Qt code for Windows with the current upstream Qt and would have to 
either stick to an old Qt or patch it. So please keep MinGW support (with a 
reasonable minimum GCC version requirement, as discussed above)!

Kevin Kofler

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

On Wednesday, 21 August 2019 15:00:14 PDT NIkolai Marchenko wrote:
> > Note: DO NOT use -static with MSVC 2017.
> 
> Can you provide the link to the bug in question? I've seen you mention it
> several times and I am curious.

https://bugreports.qt.io/browse/QTBUG-59570
https://bugreports.qt.io/browse/QTBUG-61074
https://bugreports.qt.io/browse/QTBUG-61752
https://bugreports.qt.io/browse/QTBUG-67969
https://bugreports.qt.io/browse/QTBUG-68029
https://bugreports.qt.io/browse/QTBUG-73217

https://developercommunity.visualstudio.com/content/problem/76198/vs-2017-compiler-creates-broken-debug-build-using.html
https://connect.microsoft.com/VisualStudio/feedback/details/3136520
https://developercommunity.visualstudio.com/content/problem/76198/vs-2017-compiler-creates-broken-debug-build-using.html
https://developercommunity.visualstudio.com/comments/237118/view.html

https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes-v15.7
 says it had fixed the bug, but didn't. As of 15.9 it was still there, so 
the fix is in the version after that: 16.0.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[NIkolai Marchenko]

>  Note: DO NOT use -static with MSVC 2017.
Can you provide the link to the bug in question? I've seen you mention it
several times and I am curious.

On Thu, Aug 22, 2019 at 12:58 AM Thiago Macieira 
wrote:

> On Wednesday, 21 August 2019 13:26:48 PDT Henry Skoglund wrote:
> > I thought Qt required /MD, but maybe I am an /MT ignoramus, if Qt can be
> > happily built using /MT then that would beat MinGW, since such an .exe
> > wouldn't then even require msvcrt.dll.
>
> It can be. That's what the -static-runtime option to configure does
> (additional to -static).
>
> Note: DO NOT use -static with MSVC 2017.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

On Wednesday, 21 August 2019 13:39:55 PDT Kai Pastor, DG0YT wrote:
> Note that this is the MSYS subsystem, not a MinGW subsystem of MSYS2.
> For building Windows applications, you use a MinGW subsystem, and there
> is no msys-2.0.dll.

That's just MinGW, albeit the build from MSYS2. If that's what was meant, I'm 
all for it. After the upgrade I've just run, I have GCC 9.2, which is great.

But I had understood the proposal as linking to MSYS2 libraries.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

On Wednesday, 21 August 2019 13:26:48 PDT Henry Skoglund wrote:
> I thought Qt required /MD, but maybe I am an /MT ignoramus, if Qt can be
> happily built using /MT then that would beat MinGW, since such an .exe
> wouldn't then even require msvcrt.dll.

It can be. That's what the -static-runtime option to configure does 
(additional to -static).

Note: DO NOT use -static with MSVC 2017.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Kyle Edwards]

On Wed, 2019-08-21 at 17:25 -0400, Kyle Edwards wrote:
> If you don't own the copyright, and you can't get permission from the
> copyright holder, then my guess would be no, unless you can
> successfully argue that the MSVC runtime *is* a system library (even
> though it's not distributed with Windows.)

Looks like the FSF has weighed in on this exact topic:

https://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL

You can link a GPL program against the MSVC runtime and claim it as a
system library, but you cannot then distribute the MSVC runtime with
your application. The user would have to download the runtime
themselves... which defeats the entire purpose of this exercise.

Kyle
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Henry Skoglund]

Nice. Those .exe files would be closer to 30 MB than 20 MB, right? But 
nowadays that kind of sizes are quite common/normal and does not incur 
any noticeable delays when launching them.


Building static Qt apps this way for Windows I think will be more 
popular. I wish Qt would include a static building wizard, like showing 
say the most common static build flavors as check boxes, and perhaps a 
detailed view for cherrypicking exactly what modules you want.


Rgrds Henry

On 2019-08-21 23:10, Ola Røer Thorsen wrote:
ons. 21. aug. 2019 kl. 20:54 skrev Henry Skoglund >:



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.


Agreed. I cross-build completely statically linked Qt quick apps on 
Linux using mingw-w64 and share them (.exe only, no DLLs) to 
colleagues who only run windows. Very useful! So I would not vote for 
requiring MSYS2 or similar if it would mean the end of cross building 
Windows apps on Linux (if I've understood what MSYS2 is correctly).


I would not however mind upgrading the compiler/toolchain if my 
particular one was too old for some future Qt version.


Cheers,
Ola


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Kyle Edwards]

On Wed, 2019-08-21 at 22:43 +0200, Kai Pastor, DG0YT wrote:
> Is it possible to distribute a GPL-3 licensed application this way? 
> After all, these DLLs are neither system libraries nor are they are 
> offered under compatible terms.

IANAL. If you own the copyright then you can of course license it under
GPL-3 with an exception to allow linking to the MSVC runtime.

If you don't own the copyright, and you can't get permission from the
copyright holder, then my guess would be no, unless you can
successfully argue that the MSVC runtime *is* a system library (even
though it's not distributed with Windows.)

Kyle
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Ola Røer Thorsen]

ons. 21. aug. 2019 kl. 20:54 skrev Henry Skoglund :

>
> 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.
>
>
Agreed. I cross-build completely statically linked Qt quick apps on Linux
using mingw-w64 and share them (.exe only, no DLLs) to colleagues who only
run windows. Very useful! So I would not vote for requiring MSYS2 or
similar if it would mean the end of cross building Windows apps on Linux
(if I've understood what MSYS2 is correctly).

I would not however mind upgrading the compiler/toolchain if my particular
one was too old for some future Qt version.

Cheers,
Ola
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Kai Pastor, DG0YT]

Am 21.08.19 um 21:36 schrieb Kyle Edwards:

On Wed, 2019-08-21 at 21:22 +0200, Elvis Stansvik wrote:

Why not just ship those DLLs? I wouldn't call that "verboten"
(forbidden), just a bit more to do for deployment.

It's not "verboten", but it's also not as straightforward as
redistributing free software like MinGW.

From https://docs.microsoft.com/en-us/visualstudio/productinfo/2015-red
istribution-vs :

"If you have a validly licensed copy of such software, you may copy and
distribute with your program the unmodified form of the files listed
below, subject to the License Terms for the software."

This sounds to me like you have to download a copy of Visual Studio
before redistributing the DLLs, and agree to all of the licensing
terms. (I highly doubt that this would/could actually be enforced in
any meaningful way, but for people who are picky about open source vs
proprietary licenses, this is still another unwanted hoop to jump
through.)


Is it possible to distribute a GPL-3 licensed application this way? 
After all, these DLLs are neither system libraries nor are they are 
offered under compatible terms.



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Kai Pastor, DG0YT]

Am 21.08.19 um 22:03 schrieb Thiago Macieira:

On Wednesday, 21 August 2019 12:54:11 PDT Thiago Macieira wrote:

MSYS2 is Cygwin-like. It tries to emulate a Unix on Windows. It's great for
porting Unix software to Windows and I love that it gives me a bash and
pacman for when I need to develop on Windows. But it's emulation, like:
https://github.com/Alexpux/Cygwin/blob/master/winsup/cygwin/fork.cc

$ pacman -Su
:: Starting core system upgrade...
warning: terminate other MSYS2 programs before proceeding
resolving dependencies...
looking for conflicting packages...

Packages (3) mintty-1~3.0.2-1  msys2-runtime-3.0.7-6  pacman-5.1.3-3
[...]
warning: terminate MSYS2 without returning to shell and check for updates
again
warning: for example close your terminal window instead of calling exit

This happens because msys-2.0.dll keeps a shared memory segment between all
instances MSYS2 applications, so they behave as if they were in a Unix system.

Note that this is the MSYS subsystem, not a MinGW subsystem of MSYS2. 
For building Windows applications, you use a MinGW subsystem, and there 
is no msys-2.0.dll.


https://github.com/msys2/msys2/wiki/MSYS2-introduction

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Henry Skoglund]

Hi, no I was only thinking of /MD all the time.

I thought Qt required /MD, but maybe I am an /MT ignoramus, if Qt can be 
happily built using /MT then that would beat MinGW, since such an .exe 
wouldn't then even require msvcrt.dll.



On 2019-08-21 21:59, Konstantin Tokarev wrote:


21.08.2019, 22:39, "Henry Skoglund" :

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.

Does it mean that distribution of software built with /MT runtime is illegal?



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

On Wednesday, 21 August 2019 12:54:11 PDT Thiago Macieira wrote:
> MSYS2 is Cygwin-like. It tries to emulate a Unix on Windows. It's great for
> porting Unix software to Windows and I love that it gives me a bash and
> pacman for when I need to develop on Windows. But it's emulation, like:
> https://github.com/Alexpux/Cygwin/blob/master/winsup/cygwin/fork.cc

$ pacman -Su
:: Starting core system upgrade...
warning: terminate other MSYS2 programs before proceeding
resolving dependencies...
looking for conflicting packages...

Packages (3) mintty-1~3.0.2-1  msys2-runtime-3.0.7-6  pacman-5.1.3-3
[...]
warning: terminate MSYS2 without returning to shell and check for updates 
again
warning: for example close your terminal window instead of calling exit

This happens because msys-2.0.dll keeps a shared memory segment between all 
instances MSYS2 applications, so they behave as if they were in a Unix system.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Tokarev]

21.08.2019, 22:39, "Henry Skoglund" :
> 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.

Does it mean that distribution of software built with /MT runtime is illegal?

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Tokarev]

21.08.2019, 22:56, "Thiago Macieira" :
> On Wednesday, 21 August 2019 12:29:29 PDT Massimo Callegari via Development
> wrote:
>>  Instead, please consider switching to MSYS2 for Qt6
>
> MSYS2 is Cygwin-like. It tries to emulate a Unix on Windows. It's great for
> porting Unix software to Windows and I love that it gives me a bash and pacman
> for when I need to develop on Windows. But it's emulation, like:
> https://github.com/Alexpux/Cygwin/blob/master/winsup/cygwin/fork.cc
>
> Native Windows software, which Qt on Windows is, shouldn't use that. MinGW is
> supposed to be *actual* Windows.

MSYS2 provides repositories with native toolchains (i.e., MinGW) and libraries 
as well.

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Elvis Stansvik]

Den ons 21 aug. 2019 kl 21:36 skrev Henry Skoglund :
>
> 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
https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt/).

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

Elvis

>
>
> On 2019-08-21 21:22, Elvis Stansvik wrote:
> > Den ons 21 aug. 2019 kl 20:52 skrev Henry Skoglund :
> >> 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@qt-project.org
> >>> https://lists.qt-project.org/listinfo/development
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

On Wednesday, 21 August 2019 12:29:29 PDT Massimo Callegari via Development 
wrote:
> Instead, please consider switching to MSYS2 for Qt6

MSYS2 is Cygwin-like. It tries to emulate a Unix on Windows. It's great for 
porting Unix software to Windows and I love that it gives me a bash and pacman 
for when I need to develop on Windows. But it's emulation, like:
https://github.com/Alexpux/Cygwin/blob/master/winsup/cygwin/fork.cc

Native Windows software, which Qt on Windows is, shouldn't use that. MinGW is 
supposed to be *actual* Windows.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

On Wednesday, 21 August 2019 11:35:37 PDT 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?

Clang/MinGW. However, after a quick test, turns out that this code only 
compiles under Clang trunk. Not even Clang 8 can compile it:

struct S { S(); ~S(); };

void f()
{
thread_local S s;
}

https://mingw.godbolt.org/z/nzHBEH
error: cannot compile this non-trivial TLS destruction yet

The same code compiled with the GCC/MinGW 8.2 that I have on my openSUSE 
system. (I'd have tested GCC/MinGW on Windows, but the terminal and/or bash 
refuse to paste text) I don't know when GCC implemented the functionality.

So let me instead change my request:
Can we require GCC 8 for MinGW for Qt 5.15?

That way, we can ressurrect Q_THREAD_LOCAL and eventually replace with 
thread_local.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Kyle Edwards]

On Wed, 2019-08-21 at 21:22 +0200, Elvis Stansvik wrote:
> Why not just ship those DLLs? I wouldn't call that "verboten"
> (forbidden), just a bit more to do for deployment.

It's not "verboten", but it's also not as straightforward as
redistributing free software like MinGW.

From https://docs.microsoft.com/en-us/visualstudio/productinfo/2015-red
istribution-vs :

"If you have a validly licensed copy of such software, you may copy and
distribute with your program the unmodified form of the files listed
below, subject to the License Terms for the software."

This sounds to me like you have to download a copy of Visual Studio
before redistributing the DLLs, and agree to all of the licensing
terms. (I highly doubt that this would/could actually be enforced in
any meaningful way, but for people who are picky about open source vs
proprietary licenses, this is still another unwanted hoop to jump
through.)

On the other hand, the terms of MinGW are quite clear: it's an MIT-like 
license which allows you to redistribute with only minimal requirements
(retain the copyright notice) ( http://www.mingw.org/license ).

Kyle
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Henry Skoglund]

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 :

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@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Massimo Callegari via Development]

-1 IMHO too

Instead, please consider switching to MSYS2 for Qt6. It's much more structured 
than *bare* MinGW and it offers an increasing number of libraries out of the 
box.

I believe many developers would appreciate it, and I suspect it would help the 
Qt company too when packaging non-VS-Qt for Windows.

Also, MSYS2 is used by AppVeyor as CI system. I use it for my project. It's 
fantastic.

Please, I don't want to use Micro$oft stuff.

Massimo


 Il mercoledì 21 agosto 2019, 20:37:56 CEST, Mathias Hasselmann 
 ha scritto:

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@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Elvis Stansvik]

Den ons 21 aug. 2019 kl 20:52 skrev Henry Skoglund :
>
> 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@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Henry Skoglund]

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.


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@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Mathias Hasselmann]

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@qt-project.org
https://lists.qt-project.org/listinfo/development