On 8/18/23 07:42, Zack Weinberg wrote: > On Thu, Aug 17, 2023, at 8:34 PM, Po Lu wrote: > ... > >> Given that the MinGW ABI does not constitute the GNU operating system >> executing on the MS-Windows kernel, and MSVC is not an operating system, >> such blunders should be ignored, or at least normalized... In fairness I just recently submitted the patches added them, so absent a clear notion of GNU config releases I think a grace period where we can reconsider recently added changes is acceptable.
> Even more important than this is the principle that config.sub canonical > names are *never* changed, even if they are wrong according to some external > standard. That said, I don't think we should so normalize them. I took them from LLVM, which has supported them for years and normalized in the *other* direction (i.e. to these), and Rust which follows LLVM's lead. I knew we couldn't change the old ones to normalize to the new ones, so I thought a fair middle ground was that neither would normalize to the other. For the record LLVM, Rust, and even sometimes GNU config don't treat *-*-foo-bar as *-*-$kernel-$os, but rather *-*-$kernel-$abi. Where ABI is a sort of catch-all residual. This is why e.g. riscv-unknown-linux-musl is accepted --- no one would think the Musl libc is an operating system! Rather "gnu" is interpreted to be mean "glibc, libstdcxx++, etc.". I do not think this is something to be frowned upon because "Operating System.", after all, also lacks any rigorous objective definition. At the end of the day there is: 1. The syscall interface to communicate with "the outside world". (By "kernel" we really mean syscall interface, it is possible for two different implementations, like the actual Windows kernel, and Wine, to support the same syscall interface.) 2. Other code linked into the same process. ABI covers the "most important" parts of this, especially when the userland ABI is *more* stable than the syscall ABI (Many BSDs, some Windows NT things, etc.) And even ignoring all that, the *windows*-* convention makes clear that these are variations of extra stuff atop on Windows. In many instances, it doesn't matter which one of them is in use. Using the new triples makes it easier for that agnostic code to roll with the punches. ---- My intention in adding these to GNU config was to then rework our Windows cross compilation in Nixpkgs to use them, which would mean likewise submitting patches to GCC and other things to accept them too. Normalizing them away would prevent me from doing all these other yak shaves, and trying to get the various flavors of Windows cross to work more consistently, because everything downstream from config.sub invocations would work the same way as before. IMO that would basically defeat the purpose of accepting them at all in GNU config --- better to reject that do a normalization that may not be desired. Cheers, John P.S. CCing Saleem Abdulrasool who originally added them to LLVM in https://reviews.llvm.org/D2947, and who has continued to work on LLVM-land Windows support, e.g. for Swift. (I imagine Swift, like Rust, also uses the *windows*-* ones.) Perhaps he may have some additional insight to add.
