Jacob Bachmeyer <jcb62...@gmail.com> writes: > No: MinGW is Windows native "Win32" API while a future `windows-gnu' > would be the GNU system's POSIX API on an NT kernel. These are *very* > different configurations; `windows-gnu' would more closely resemble > Cygwin.
This is not what the `x86_64-pc-windows-gnu' configuration presently canonicalized by config.sub represents. > I say it would be more appropriate to accept `x86_64-pc-mingw64' as a > short form for `x86_64-pc-windows-mingw64', since Wine could enable a > `x86_64-pc-linux-mingw64' platform to exist. (Wine's goal is that > that platform should be indistinguishable from > `x86_64-pc-windows-mingw64', but it is certainly a distinct > configuration from the user's perspective.) Wine is a compatibility layer that emulates the MS-Windows kernel. It is not config's role to report the intricacies of the operating system implementation, only details that affect user programs running under that operating system. > But they already have drifted: config tuples were originally triplets > and now often feature a 4-element CPU-VENDOR-KERNEL-OS form Only as a result of a technical need to distinguish Linux-based GNU systems from other GNU systems. Absent that requirement, we would simply call GNU/Linux systems *-*-gnu, Alpine *-*-alpine, and Android *-*-android. > but several existing tuples use a libc or ABI name in place of a > kernel and/or operating system. In each of those cases, the ABI name _can_ be construed as a kernel (since there is no kernel at all), or the libc name refers to a general category of OS. Neither of these situations are applicable to MinGW or MSVC. > I simply note this and suggest recognizing this fact that config > tuples are actually now currently 3-or-4-of-5 elements. The GNU > system is definitely flexible enough for that 5-element form to be > appropriate: `CPU-VENDOR-linux-gnu' (GNU/Linux, implied to be using > glibc) and `CPU-VENDOR-linux-gnu-musl' (GNU/Linux using musl libc) are > plausibly distinguishable, for example, and could even both be useful > on the *same* machine, if, for example, some low-level system > utilities are linked against musl libc while most user programs use > glibc. Such configurations do not exist, so we need not provide for them in config.*. And in any case, these ``low level utilities'' would be configured for *-*-linux-musl, while user programs would be configured for *-*-linux-gnu. I see no reason config.* must take special measures to recognize these Frankenstein systems, since the C library used to build some system utilities has no bearing on the operation of other user programs built for *-*-linux-gnu.
