|
From: | John Ericson |
Subject: | Re: config.sub should normalize *-*-windows-* |
Date: | Mon, 21 Aug 2023 00:31:14 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 |
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.
JohnP.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 <jcb62281@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.
[Prev in Thread] | Current Thread | [Next in Thread] |