Thanks Jacob,
That's absolutely right that Win NT supports multiple personalities and
so all sorts of things are possible. (Indeed that is how WSL1 worked.)
MinGW stands for "Minimalist GNU for Windows" [1], and I suspect that is
why Saleem choose windows-gnu in that commit almost a decade ago. I
supposed we could say that "minimalist GNU" is not "GNU", and do
windows-mingnu or something, and then I could submit an LLVM patch to
try to support that. But I suppose I lean towards support configs that
at least one of GCC or Clang supports already, rather than making up
completely new stuff.
Also, I would like to point out that the "scales to more variations"
argument is not at all hypothetical. If one looks at [2] one will see
that MSYS is a variation of Cygwin, and a mingw-style environments can
be made from the newer ucrt or older msvcrt. Today there are just too
many subtle variations to capture them all with sensible. It looks like
MSYS [3] reuses a triple for multiple configurations, and just relies on
users getting the PATH right, but that clearly isn't ideal. Creating
windows-* variants to handle them all in a consistent and predictable
manner is much better.
John
P.S. I've also CC'd Martin Storjso who has worked on LLVM MinGW things
recently
[1]: https://en.wikipedia.org/wiki/MinGW
[2]: https://www.msys2.org/docs/environments/
[3]: https://packages.msys2.org/package/mingw-w64-x86_64-gcc
https://packages.msys2.org/package/mingw-w64-ucrt-x86_64-gcc
On 8/20/23 22:40, Po Lu wrote:
Jacob Bachmeyer <jcb62...@gmail.com> writes:
At this time, yes. However, the GNU utilities are designed to be
fairly portable and the NT kernel was designed to support multiple
ABIs, so a hypothetical port of GNU to run under MS-Windows is within
the realm of possibility. (In fact, the underlying architecture of NT
should have all of the primitives needed to support HURD or a closely
related system.) It is more likely that this would be implemented on
ReactOS (which aims for ABI compatibility with NT 5.1, is a stable
target, and is Free) first, but a hypothetical `x86_64-pc-windows-gnu'
(or perhaps `x86_64-pc-reactos-gnu') config tuple *is* a future
possibility.
This hypothesizing is not relevant here. x86_64-pc-windows-* represents
MinGW, and should be normalized correspondingly.
And what would we canonicalize `x86_64-pc-windows-gnu' to, other than
itself, currently?
x86_64-pc-mingw64, which I mentioned at the outset of this thread.
It appears that config tuples may be drifting towards a 5-element
CPU-VENDOR-KERNEL-OS-LIBCABI form, with each of the last three
elements potentially optional, which makes any real tuple ambiguous,
except that the valid strings for KERNEL, OS, and LIBCABI are from
distinct sets.
Configuration tuples don't ``drift'', and they certainly should not
change or duplicate other triplets.
