https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126608
--- Comment #4 from Zhongteng Gui <dragon-archer at outlook dot com> --- (In reply to nightstrike from comment #3) > As you know, GCC can be hosted on native windows, outside of an MSYS1 / > MSYS2 / Cygwin environment. The mingw symlink is analogous to the /usr/local > that's standard on Unix based systems, which would otherwise have to be C:\ > or similar on a Windows platform. AFAIK, native Windows GCC can be (and ideally if) fully relocatable. That means that it doesn't have to hardcode any specific paths, and it can find all needed file (headers, libraries, startup files) based on the location of gcc.exe. Currently we've nearly achieved this in MSYS2 GCC. Also, relying on /mingw = C:\mingw is hacky, what if you run it from D:\? > How does your change affect a native compiler in that regard, where for > example C:\mingw has been the standard since the beginning of mingw? Or does > this change only affect cross compilers, hosted on MSYS, etc. systems? Regarding the already applied patch, the FLAGS_FOR_TARGET has always been redundant: the required directories is already added either by default (system include) or by other bootstrap scripts. Regarding my latest patch at https://gcc.gnu.org/pipermail/gcc-patches/2026-October/735667.html, everything relying on /mingw/{include,lib} can still work. I just make it possible to get rid of them through configure options.
