1. I suggest to add a toggle to GCC to set _WIN32_WINDOWS and _WIN32_WINNT with configure to support legacy systems windows 9x, windows NT 2000 and xp better. 2. Build order should change to first build GCC with --without-headers --disable-shared �Cdisable-threads �Cdisable-sjlj-exceptions �Cdisable-hosted-libstdcxx to build a freestanding GCC then use that to build mingw-w64. Then rebuild entire GCC. Freestanding C++ headers should build before building mingw-w64-headers and mingw-w64-crt.
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows From: LIU Hao<mailto:[email protected]> Sent: Wednesday, October 12, 2022 00:08 To: Jacek Caban<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Mingw-w64-public] [RFC] Integrating mcfgthread with mingw-w64 CRT 在 2022/10/12 03:55, Jacek Caban 写道: > Is there anything that mcfgthread achieves that can't be fixed in GCC's win32 > model? This sounds to > me like that GCC is the right place to fix things, possibly by merging parts > of mcfgthread into GCC > itself. I really don't like the idea of adding another threading model > instead of fixing the > existing one. It adds more fragmentation, more maintenance and more user > confusion. I think it's > better to fix the root of threading support problems instead. The obvious problem is that mcfgthread is functional on only Windows 7 and above, while (I don't know for sure) win32 should continue to work on XP, 2000, or even 9x. Originally there was only mutex, condition variable, once flag, thread and thread-specific key in mcfgthread. When I considered that it should be possible to join with the main thread from another one, it would be necessary to have a static thread-control structure for the main thread, allocated upon library initialization. (N.B. The Windows thread exit code is not an option, because pthread wants a `void*` which would be truncated on 64-bit Windows.) Later, `__cxa_atexit()` was added to address the issue about order of destruction, which also required a destructor queue. The same went for `__cxa_at_quick_exit()`. While some people do prefer static linking, ideally these global data should be unique within a single process, and were necessary to be part of a DLL. This approach was much similar to the legacy `mingwthrd` library. Technically, this can be solved with named shared memory [1], and is not a requirement any more. Therefore it has become a personal preference, to not maintain something as a part of GCC, mostly due to their lack of enthusiasm about Windows. [1] https://github.com/lhmouse/mcfgthread/issues/70 -- Best regards, LIU Hao
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
