On 2026/10/09 18:59, Jonathan Yong wrote: > On 10/8/26 18:08, Zhongteng Gui wrote: >> 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? >> > I would prefer native Cygwin to be tested as well since Cygwin/mingw/w32api > is closely linked. The less surprises the better. Only x86_64 Cygwin needs to > be tested, the 32-bit Cygwin has been retired.
Fine. I've successfully built native Cygwin gcc with cygport and my patch (v3, since cygport doesn't autoreconf) applied. Nothing breaks, I espcially checked gcc -xc++ /dev/null -E -v for the default search paths.
