On Sunday 30 August 2026 21:37:09 Zhongteng Gui wrote: > 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 -###` >
Well, this is not only about mingw32, but also about cygwin. And if the gcc still support mingw32 (or at least present that it support it) then it is not a good idea to explicitly break it just by an argument "I doubt that somebody is using it". I can understand that gcc people do not want to support it anymore and will remove it. That is fine, I have no reason to oppose it, but it should be official and officially removed. I do not like the fact that some "random mingw-w64" change for gcc will break something non-mingw-w64 (even if it has small or zero usage). And still need to think about cygwin. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
