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.
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.
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.
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.)
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.
But they already have drifted: config tuples were originally triplets
and now often feature a 4-element CPU-VENDOR-KERNEL-OS form, but several
existing tuples use a libc or ABI name in place of a kernel and/or
operating system. 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.
-- Jacob
