On 2026/10/09 13:16, Trevor Gross wrote: > On Thu Oct 8, 2026 at 11:48 PM CDT, Zhongteng Gui wrote: >> On 2026/10/09 11:03, Trevor Gross wrote: >>> On Aug 5, 2026, 3:18 AM, Zhongteng Gui <[email protected]> wrote: >>> >>> For what it's worth, I have been using the two similar but slightly >>> different patches and have been able to bootstrap on Windows >>> successfully, it doesn't work without them. I don't know enough about >>> how these paths work to know what's best, though. >> >> Actually, my patch above IS based on the older patch by mingwandroid. You >> can see the full evolution at >> https://github.com/msys2/MINGW-packages/pull/29280, you can also find many >> other attempts I've tried here >> (some are collapsed to make the overview cleaner). >> >> This patch have already been used by MSYS2 for several months, and also >> shared to conda-forge, so I think >> there's no problem that it bootstrap successfully for both pure MinGW-w64 >> (both host and target is MinGW-w64), >> or completely cross MinGW-w64 (host is Linux/Darwin, target is MinGW-w64, >> tested by conda-forge's CI). >> >> The remaining triplet to test is Cygwin-MinGW cross compiler. I'll try >> bootstrap it locally these days. > > Didn't mean to imply it's different or novel :) just a +1 that > bootstrapping on Windows has been broken for as long as I've tried using > it, and that I've been able to successfully do the very occasional > bootstrap with a similar fix.
Ah yes, thanks for emphasizing this. All current GCC distribuitions on Windows have to greatly patching it to successfully bootstrap. That's why I said before that it's very "hacky", as most of them are using sed to hardcode the full Windows path at build into gcc/config/mingw/mingw32.h. I'd like to also post some more reference[1] for those interested: I've done lots of experiments on bootstrapping GCC on Windows (mainly under MSYS2, but I guess can also apply to Cygwin, as they all auto convert paths). The latest progress is that with my patch applied, as long as you don't want to enable ada, you can fully use Unix-style paths, and completely avoid hardcode any Windows paths into build results. Ada is an exception because gnatlink launches xgcc itself (instead of through Bash/Make), so you have to pass an Windows path into --with-build-sysroot, which will be saved as configure options. Fortunately, this will never be parsed (I mean, trying to access) at runtime. [1]: https://github.com/msys2/MINGW-packages/blob/7c4b39d9bb2605b63a904a031b0aec309b4ac548/mingw-w64-gcc/PKGBUILD#L277 > >>> They're also on my branch at [1]. Disregard the patches changing output, >>> that's an unsuccessful attempt to resolve [2]. >>> >>> [1]: >>> https://github.com/gcc-mirror/gcc/compare/master...tgross35:gcc:patch-win-build >>> [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121943 >> >> IMHO this bug is unrelated to our patches? Though it'd be nice if it can be >> resolved one day, > > Yup unrelated, that's just a branch I had linkable. But yeah, it did > make doing a minor change difficult when I couldn't even test it. > > - Trevor
