|
From: | Jacob Bachmeyer |
Subject: | Re: config.sub should normalize *-*-windows-* |
Date: | Sun, 20 Aug 2023 21:21:37 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 |
Po Lu wrote:
"John Ericson" <list@johnericson.me> writes:[...]Had those Windows-based platforms been introduced later, something like the configs that Saleem added to LLVM would have been used from the get go --- grouping the Windows-based platforms and grouping the Linux-based platforms are both advantageous ways of categorizing things, and advantageous for the same reasons.We are trying to develop the GNU operating system, and it is in our interest to convey the distinction between GNU systems employing the Linux kernel, and other operating systems that are - by happenstance - built on top of the same kernel. OTOH, MinGW does not provide an operating system founded upon the Windows kernel, so it is incorrect to apply the: machine-vendor-kernel-OS quadruplet scheme to it. To rub salt into the wound, the GNU operating system does NOT run under a MS-Windows kernel. So ``windows-gnu'' is not just conjecture, it is also a misnomer.
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.
As I said in the other email, I am not forcing anyone to do anything.You are, as users will soon begin to provide invalid triplets such as `x86_64-pc-windows-gnu' to their configuration files. And instead of canonicalizing them, the express purpose of config.sub, they are reproduced verbatim, much to the detriment of configure scripts and to the chagrin of package maintainers.
And what would we canonicalize `x86_64-pc-windows-gnu' to, other than itself, currently?
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.
-- Jacob
[Prev in Thread] | Current Thread | [Next in Thread] |