On 2026/10/08 23:37, Jonathan Yong wrote: > On 10/8/26 06:25, Zhongteng Gui wrote: >> Oops, I forgot to use reply-all in the previous email. Sorry for the >> duplication! >> >> On 2026/10/08 07:47, Jonathan Yong wrote: >>> On 10/7/26 18:14, Zhongteng Gui wrote: >>>> Ping^3. >>>> >>>> Cc Jonathan Yong, I don't want to be rude, but it looks like few people >>>> here >>>> are interested in mingw-related patches 🙁 >>>> >>>> The patch has generally working well in both MSYS2 and Conda-forge for >>>> several >>>> months, except: >>>> >>>>>>> +#if !defined(STANDARD_STARTFILE_PREFIX_2) && ! >>>>>>> defined(CROSS_DIRECTORY_STRUCTURE) >>>>>>> +#define STANDARD_STARTFILE_PREFIX_2 "" /* MSYS2 doesn't use /usr/lib >>>>>>> for >>>>>>> MINGW */ >>>> >>>> This part causes a regression in conda-forge, as they use /usr/lib instead >>>> of /lib, >>>> see also >>>> https://github.com/conda-forge/ctng-compilers-feedstock/issues/229. >>>> >>>> It's OK to revert this part, and keep this as a MSYS2-specific patch. Or >>>> keep >>>> this part, and let conda-forge to patch it. >>>> I'm not sure which one is better and/or more acceptable. >>>> >>> I am OK for removing the newlib combined tree build flags, but I am rather >>> ambivalent about the other changes since mingw* target gcc has always been >>> expecting its headers and libraries under /mingw. >>> >> >> As I've said in the original commit message, I did lots of searches before, >> and I think this is >> inherited from the very-old MSYS 1 together with MinGW (no -w64). Also, I >> doubt it can't even build >> some older GCC versions, not to say latest GCC 16/17. (The last proved >> version >> was GCC 6, see [1]). >> >> Most modern distributions (that can build GCC 16) as I've listed in the >> commit >> message usually use `sed` >> to replace `/mingw` with either `/usr` or their own prefixes. This is very >> hacky, and I think (and it'v proved >> to work in MSYS2 and conda-forge) that it's better to use --sysroot with no >> special prefixes. >> >>> Please resend the patch that removes just the FLAGS_FOR_TARGET for now. >>> >> >> I'm attached an updated patch thet just removes FLAGS_FOR_TARGET. >> Not very sure about the commit message in this case. >> >> BTW, thanks a lot for your quick respond! I'd appreciate it if you could also >> review my other mingw-related patches: >> >> - [PATCH] lto, mingw: Do not export symbols from some frontends [2] >> - [PATCH] jit: set JIT_LDFLAGS for MinGW [PR125229] [3] >> - [PATCH] mingw32crt: Remove outdated target [PR127137] [4] >> - [PATCH] mingw: Remove deprecated libs from spec [PR127135] [5] >> >> About the last one, there's also some discussion in MinGW-w64's mailling >> list [6] >> >> [1]: https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version6/ >> [2]: https://gcc.gnu.org/pipermail/gcc-patches/2026-August/727191.html >> [3]: https://gcc.gnu.org/pipermail/gcc-patches/2026-August/728804.html >> [4]: https://gcc.gnu.org/pipermail/gcc-patches/2026-August/729350.html >> [5]: https://gcc.gnu.org/pipermail/gcc-patches/2026-August/729334.html >> [6]: https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/ >> SL2P216MB227115CAA376A87289A35514EFAB2%40SL2P216MB2271.KORP216.PROD.OUTLOOK.COM/ >> --- >> >> From 92e86faf25ae7f5a95c1572fc93b2a2bc62a7670 Mon Sep 17 00:00:00 2001 >> From: Zhongteng Gui <[email protected]> >> Date: Thu, 8 Oct 2026 13:56:45 +0800 >> Subject: [PATCH v2] mingw: Remove outdated /mingw stuff from FLAGS_FOR_TARGET >> [PR126608] >> >> /mingw is only used by MSYS 1, which has been obsolete for a long time. >> The current users of target *-w64-mingw32 either uses their own prefix >> (MSYS2 and its derivatives, w64devkit, etc.), or use the default prefix >> /usr (Cross-compiling on linux, e.g. Conda-forge). >> >> More cleanups of /mingw may be done in future patches. >> >> ChangeLog: >> >> PR target/126608 >> * configure.ac (x86_64-*mingw* | *-w64-mingw*): Do not use >> /mingw symlink. >> >> Signed-off-by: Zhongteng Gui <[email protected]> >> --- >> configure.ac | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/configure.ac b/configure.ac >> index c5de225b0ac..c81755ebbb6 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -3948,9 +3948,7 @@ esac >> case "$target" in >> x86_64-*mingw* | *-w64-mingw*) >> - # MinGW-w64 does not use newlib, nor does it use winsup. It may, >> - # however, use a symlink named 'mingw' in ${prefix} . >> - FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L${prefix}/${target}/lib - >> L${prefix}/mingw/lib -isystem ${prefix}/${target}/include -isystem ${prefix}/ >> mingw/include' >> + # MinGW-w64 does not use newlib, nor does it use winsup. No special flags >> needed. >> ;; >> *-mingw*) >> # MinGW can't be handled as Cygwin above since it does not use newlib. > > > With LH's comment, I am even less confident of the changes until a full gcc > bootstrap on Windows, Cygwin and its cross-compilers are done as a build test. > > For building gcc and cross compilers on Cygwin with cygport, download and > install all the dependencies as defined in cygport via Cygwin setup, and then > do: > > cygport [cygport file] download prep compile install package > > Relevant cygport files: > https://cygwin.com/cgit/cygwin-packages/gcc/tree/gcc.cygport > https://cygwin.com/cgit/cygwin-packages/mingw64-x86_64-gcc/tree/mingw64-x86_64- > gcc.cygport > > You can add your patches to the PATCH_URI to test out your changes.
Thanks, I'll try bootstrap mingw64-x86_64-gcc on Cygwin with this patch and test it. Considering that this change only effects MinGW targets, I guess there's no need to bootstrap "native Cygwin" gcc? > > Patch [2] touches other host platforms, I would prefer a check be done in > configure for mingw hosts handle the changes cleanly. I'll try adjust this patch later, not very sure whether possible. > > In patch [3], please untangle the LIBGCCJIT_EXTRA_OPTS and JIT_LDFLAGS paths > into separate conditionals so it is much clearer which platform is doing what. This've been done in https://gcc.gnu.org/pipermail/jit/2026q4/002188.html Thanks for suggestion, this helped me find a potential bug. > > Patch [4] accepted and pushed to master branch. Great thanks to you! > > Patch [5] I am unsure of the need for this change even if it does nothing > anymore today. > Well, I think this is a common circular dependency problem on technical debt: Once something was used by default, even if newer provider think it's redundant, they have to still provide a dummy placeholder for existing code. Then the user is less motivated to change it, as "it still works". To solve this, I think it'd be better to first update the now-latest user to not use it any more, then after several years, the then-latest provider may be able to stop providing it.
