Re: config.sub should normalize *-*-windows-*

[Jacob Bachmeyer]

Po Lu wrote:
> Jacob Bachmeyer <jcb62281@gmail.com> writes:
>
>   
> > 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.
> >     
>
> This is not what the `x86_64-pc-windows-gnu' configuration presently
> canonicalized by config.sub represents.
>   

Then its present use is *wrong* and a bug that should be fixed.

> > 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.)
> >     
>
> Wine is a compatibility layer that emulates the MS-Windows kernel.  It
> is not config's role to report the intricacies of the operating system
> implementation, only details that affect user programs running under
> that operating system.
>   

As I said, Wine's goal is that `x86_64-pc-linux-mingw64' be 
indistinguishable from `x86_64-pc-windows-mingw64' but that does not 
preclude using the KERNEL-OS form.

> > But they already have drifted:  config tuples were originally triplets
> > and now often feature a 4-element CPU-VENDOR-KERNEL-OS form
> >     
>
> Only as a result of a technical need to distinguish Linux-based GNU
> systems from other GNU systems.  Absent that requirement, we would
> simply call GNU/Linux systems *-*-gnu, Alpine *-*-alpine, and Android
> *-*-android.
>   

It is a little more complex than that:  the GNU system theoretically can 
run on any of multiple kernels.  While Linux is most commonly used, GNU 
HURD is still in development and I understand that there is a Debian 
variant using the GNU utilities on a FreeBSD kernel.

> > but several existing tuples use a libc or ABI name in place of a
> > kernel and/or operating system.
> >     
>
> In each of those cases, the ABI name _can_ be construed as a kernel
> (since there is no kernel at all), or the libc name refers to a general
> category of OS.  Neither of these situations are applicable to MinGW or
> MSVC.
>   

Arguably, MinGW *is* an ABI name.

> > 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.
> >     
>
> Such configurations do not exist, so we need not provide for them in
> config.*.  And in any case, these ``low level utilities'' would be
> configured for *-*-linux-musl, while user programs would be configured
> for *-*-linux-gnu.  I see no reason config.* must take special measures
> to recognize these Frankenstein systems, since the C library used to
> build some system utilities has no bearing on the operation of other
> user programs built for *-*-linux-gnu.

Think about why the GNU project pushes to call the common system 
"GNU/Linux" and you should see the reason for using `*-*-linux-gnu-musl' 
to express a GNU/Linux system using musl libc.


-- Jacob