On 2026/08/30 17:57, Pali Rohár wrote: > On Sunday 30 August 2026 11:30:33 Pali Rohár wrote: >> On Sunday 30 August 2026 17:14:32 Zhongteng Gui wrote: >>> On 2026/08/30 15:44, Pali Rohár wrote: >>>> On Sunday 30 August 2026 03:24:26 Kirill Makurin wrote: >>>>> Zhongteng Gui <[email protected]> wrote: >>>>> >>>>>> Hi, I found that many libraries provided by mingw-w64-crt are actually >>>>>> empty, >>>>>> for example, libmingwthrd and libmoldname. Unfortunately, they're still >>>>>> hardcoded in GCC's default specs, so I'd like to first remove them from >>>>>> there, >>>>>> then maybe in the future we can remove them from mingw-w64. >>>>> >>>>> These empty libraries are kept exactly to avoid breaking older gcc/clang >>>>> versions, as they hardcode them. >>>> >>>> Exactly. Those libraries need to stay here to make sure that older gcc >>>> versions will work. >>> >>> Fine, I understand these libraries cannot be removed from mingw-w64 for a >>> long >>> time, I just want to be sure they're useless now, so I can remove them from >>> new >>> GCC's specs. >> >> Note that gcc spec is a template for cygwin, mingw32 and mingw-w64 >> targets. So beware to not break remaining two targets, this needs to be >> mingw-w64 specific change. >> >>> I've submitted a slightly modified patch at >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127135 > > Now I'm looking at your change and it is modifying also the mingw32.h > file which is shared between mingw32 and mingw-w64. So this is something > which should stay as is, to not break other targets. >
I doubt whether we really need to keep compatiablity with old MinGW.org. AFAIK, https://sourceforge.net/projects/mingw/ has never updated for nearly 10 years, and their *latest* build is gcc-6.3.0. I don't think GCC 16 or later can be compiled using MinGW.org, and actually nobody is doing this. It's true that it's generally better to not breaking anything else, but: 1. In our case, it's somehow hard to actually distinguish between MinGW.org and MinGW-w64: few things check for `-w64-`, while most just check for `-mingw*`. To be more specific, libgcc/config/i386/t-mingw32 is used by both MinGW.org and MinGW-w64, and there's no "overlay layers" for MinGW-w64 specific. 2. Regarding gcc/config/mingw/mingw32.h, it's true that it will be overriden by gcc/config/i386/mingw-w64.h, so it seemes unnecessary to edit that file. However, I think it would be misleading to keep it as is. Actually, keeping compatiablity with MinGW.org has made building for MinGW-w64 hacky in the past in many ways. This partly comes from many downstream maintainers are unfamiliar with both MinGW and MinGW-w64, and partly comes from lots of old "workarounds" for MinGW are not only useless for MinGW-w64, but also causing more problems. This becomes worse when distributions of MinGW-w64 have to "workaround" problems caused by old "workarounds": they usually just "happenes to compile". See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126608 https://github.com/msys2/MINGW-packages/pull/29280 BTW, LLVM also have similar problems like hardcoding /mingw/lib and linking -lmoldname, though I don't have time to create PRs for it recently. For anyone interested, this can be seen from simply `clang -xc /dev/null -v -###` _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
