On 2026/10/08 23:37, Jonathan Yong wrote:
> On 10/8/26 06:25, Zhongteng Gui wrote:
>> [...]
>>
>> 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/
>> ---
>>
>> [...]
>
>
> 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.
>
I've revised my patch and tested it with cygport. Everything works well.
Changes since v2: Revised commit message. Regenerate configure.
I've looked further into the difference between the Cygwin and MSYS2
cross-toolchain layouts. TL;DR, the /mingw component comes from
cygport's installation-prefix policy.
There are two related paths through cygport. For cross-toolchain
packages (like cross gcc), toolchain.cygclass defines TOOLCHAIN_SYSROOT as
/usr/${CTARGET}/sys-root and TOOLCHAIN_PREFIX as that directory followed
by __target_prefix(), which returns /mingw for MinGW targets. Note that
the __target_prefix isn't passed to configure as --prefix. Instead,
__prep_libtool_modules from src_postinst.cygpart moves artifacts to that dir:
mv ${ltlibdir}/${dlname}
${D}/usr/${CTARGET}/sys-root/$(__target_prefix)/bin/
For target libraries and headers, the relevant mechanism is
cross.cygclass and __host_prefix(). Here MinGW is the host of the
package being built, rather than the target of a compiler being built.
cross.cygclass sets CROSS_SYSROOT to /usr/${CHOST}/sys-root, and
__host_prefix() returns ${CROSS_SYSROOT}/mingw for a MinGW host.
cygconf() uses __host_prefix() to supply its default --prefix and
--exec-prefix arguments. Thus, unless overridden by the recipe,
mingw-w64 is configured with an installation prefix such as
/usr/x86_64-w64-mingw32/sys-root/mingw. Its normal installation rules
then place the headers and CRT files under that prefix.
It's noteworthy to distinguish the sysroot's /mingw directory from the
${prefix}/mingw path removed from FLAGS_FOR_TARGET: with Cygwin's GCC
configuration, the latter is /usr/mingw (which doesn't exist), not
/usr/x86_64-w64-mingw32/sys-root/mingw.
Unfortunately, the remaining parts of my original patch may breaks Cygwin's
assumption. I'll try implement it in a different way.
Rough idea: Keep /mingw/{include,lib} as an default option, and allow
overriding it through configure options. Currently
--with-native-system-header-dir and --with-local-dir are all discared for
MinGW-w64 targets. Still not sure how to deal with
STANDARD_STARTFILE_PREFIX_{1,2}, as there seems no existing configure options.
---
>From add4447b142b3b2febf93428fe8c5b70caae8254 Mon Sep 17 00:00:00 2001
From: Zhongteng Gui <[email protected]>
Date: Thu, 8 Oct 2026 13:56:45 +0800
Subject: [PATCH v3] mingw: Remove redundant target search flags [PR126608]
The top-level configure adds explicit library and system header search
paths under ${prefix}/${target} and ${prefix}/mingw to FLAGS_FOR_TARGET
for MinGW-w64 targets.
The target tool directories are already covered by the generic
build_tooldir search flags. For sysroot-based configurations, target
headers and libraries are found through the configured sysroot and
the target's default search paths.
These flags are not only redundant, but also may change the search
order, as many downstream use `sed` to convert all `/mingw` to their own
prefix, which accidentally make system libraries be preferred instead of
newly-built gcc libraries, which can cause issues when changing
important settings, e.g. thread model. See also:
https://github.com/msys2/MINGW-packages/pull/29280#issuecomment-5180468708
Remove these additional MinGW-w64 search flags. This does not change
the default header or startfile directories, including the /mingw
directories within the sysroot used by Cygwin-hosted MinGW-w64 cross
compilers.
PR target/126608
ChangeLog:
* configure.ac (x86_64-*mingw* | *-w64-mingw*): Stop appending
redundant search flags to FLAGS_FOR_TARGET.
* configure: Regenerate.
Signed-off-by: Zhongteng Gui <[email protected]>
---
configure | 4 +---
configure.ac | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/configure b/configure
index 083e8823d2b..007477f6393 100755
--- a/configure
+++ b/configure
@@ -11879,9 +11879,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.
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.
--
2.56.0.windows.2
