Re: [Development] Requiring minimum GCC 7/MinGW (was: Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral))
On Sunday, 25 August 2019 01:05:23 PDT Ray Donnelly wrote: > > > just mentioning it: > > > https://github.com/msys2/MINGW-packages/issues/2519 > > > > The description of the bug says "winpthreads", which means it's not MinGW, > > it's Cygwin/MSYS2. > > This is completely incorrect. Thiago I would expect better from you. I've already been corrected. But in my defence, here was my line of thinking: 1. searched libgcc source code for the _gthreads implementation 2. found code using Win32 directly (like TlsAlloc) 3. concluded libgcc does not need pthread emulation 4. concluded that anyone using pthread emulation was Cygwin Conclusion #3 is correct. Conclusion #4 wasn't, because I failed to take into consideration that the pthread emulation may be needed for other features which Qt doesn't need (namely, std::thread). -- 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] thread_local: replacing GCC with Clang for MinGW
On Sunday, 25 August 2019 00:44:51 PDT Olivier Goffart wrote: > One could fix the leak by re-implementing DllMain in QtCore and using the > DLL_THREAD_DETACH hook to delete the QAdoptedThread > https://docs.microsoft.com/en-us/windows/win32/dlls/dllmain > > That would fix the leak for dynamic Qt build. > > But for static build we would need another trick. > The comments from this file are pretty interesting and would provide a > solution: > https://github.com/rust-lang/rust/blob/master/src/libstd/sys/windows/thread > _local.rs#L130 I'm not interested in further adding workarounds for compiler shortcomings that may be fixed in the very next release of those compilers when we already have a working solution. People using std::thread are unlikely to be using QThreadStorage. If they have a problem with thread_local and want to use QThreadStorage, they can change the thread start too. -- 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] Requiring minimum GCC 7/MinGW (was: Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral))
On Fri, 23 Aug 2019, 17:11 Thiago Macieira, wrote: > On Friday, 23 August 2019 00:12:50 PDT Roland Winklmeier wrote: > > Just for your awareness: There is an old bug related to thread_local in > > MinGW which afaik was never fixed. It compiles correctly, but every > > executable crashes during shutdown. Not sure if this relevant in this > case, > > just mentioning it: > > https://github.com/msys2/MINGW-packages/issues/2519 > > The description of the bug says "winpthreads", which means it's not MinGW, > it's Cygwin/MSYS2. This is completely incorrect. Thiago I would expect better from you. > libgcc on pure MinGW doesn't use winpthreads, it uses Win32. > > Anyway, let's apply Q_THREAD_LOCAL. If that causes GCC-built MinGW > applications to crash on exit, then we stop using GCC and switch to Clang. > > -- > 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)
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] thread_local: replacing GCC with Clang for MinGW
On 24.08.19 18:04, Thiago Macieira wrote: [...] That means we must continue to use QThreadStorage where we need non-POD thread-local storage, which only works[*] in QThread-started threads. [*] it won't crash if you use QThreadStorage with a thread started with something else, despite what the source code says, but it will leak memory. The leak will only happen on Windows. One could fix the leak by re-implementing DllMain in QtCore and using the DLL_THREAD_DETACH hook to delete the QAdoptedThread https://docs.microsoft.com/en-us/windows/win32/dlls/dllmain That would fix the leak for dynamic Qt build. But for static build we would need another trick. The comments from this file are pretty interesting and would provide a solution: https://github.com/rust-lang/rust/blob/master/src/libstd/sys/windows/thread_local.rs#L130 -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
