On 8/24/23 23:54, Jacob Bachmeyer wrote:
John Ericson wrote:
This is why I opened with "Operating System" lacks a coherent
objective definition.
[...]
As I understand, historically, "operating systems" were proprietary
monoliths and the GNU Project originally expected to produce another
Thanks Connor. I think we are both on the same page!
On 8/24/23 14:51, connor horman wrote:
It seems to me reading this thread that we've come into two
conflicting realities:
* There exists targets that need to be distinguished, and
* They are not distinct in any component that config.sub
connor horman writes:
> It seems to me reading this thread that we've come into two
> conflicting realities: * There exists targets that need to be
> distinguished, and * They are not distinct in any component that
> config.sub has, therefore they cannot and should not be distinguished.
>
>
John Ericson wrote:
This is why I opened with "Operating System" lacks a coherent
objective definition.
The more pugilistic message is to say the rest of the world doesn't
think the GNU operating system exists --- that there is simply a
choice of kernel (Linux, k*BSD, Hurd, something
Adam Joseph wrote:
Quoting Jacob Bachmeyer (2023-08-21 19:35:05)
No, we are not. CPU-VENDOR-KERNEL-OS-LIBCABI, with at least one of the
If you want to redefine existing terms, please be forthright about the fact that
your proposal does so.
I argue that this is something that has
It seems to me reading this thread that we've come into two conflicting
realities:
* There exists targets that need to be distinguished, and
* They are not distinct in any component that config.sub has, therefore
they cannot and should not be distinguished.
mingw and msvc both use the NT kernel,
This is why I opened with "Operating System" lacks a coherent objective
definition.
The more pugilistic message is to say the rest of the world doesn't
think the GNU operating system exists --- that there is simply a choice
of kernel (Linux, k*BSD, Hurd, something else...) and choices of
Quoting Jacob Bachmeyer (2023-08-21 19:35:05)
> No, we are not. CPU-VENDOR-KERNEL-OS-LIBCABI, with at least one of the
If you want to redefine existing terms, please be forthright about the fact that
your proposal does so.
This usage is in conflict with the existing definition; LIBC and ABI are
Jacob Bachmeyer writes:
> There are several GNU/Linux distributions that either use or can use
> musl libc already. (See:
> https://en.wikipedia.org/w/index.php?title=Musl=1164590075>)
> Musl libc does not have the same features as GNU libc, so it is
> rightly a different ABI target, however,
Po Lu wrote:
Jacob Bachmeyer writes:
No, we are not. CPU-VENDOR-KERNEL-OS-LIBCABI, with at least one of
the latter three omitted, fits the bill. In that case, the reference
to MinGW means that "OS" and/or "KERNEL" are omitted and MinGW is the
ABI. The next logical extension is to allow
Jacob Bachmeyer writes:
> No, we are not. CPU-VENDOR-KERNEL-OS-LIBCABI, with at least one of
> the latter three omitted, fits the bill. In that case, the reference
> to MinGW means that "OS" and/or "KERNEL" are omitted and MinGW is the
> ABI. The next logical extension is to allow all five to
Po Lu wrote:
Jacob Bachmeyer writes:
[...]
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
Jacob Bachmeyer writes:
> Then its present use is *wrong* and a bug that should be fixed.
The subject of this thread, indeed.
> 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
John Ericson wrote:
On Mon, Aug 21, 2023, at 1:17 AM, Po Lu wrote:
Jacob Bachmeyer mailto:jcb62...@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;
Jacob Bachmeyer writes:
> I said "with only 3-or-4-of-5 elements present"; that using all 5
> elements is currently invalid does not change that we effectively
> /have/ 5 elements, with a restriction that only 3 or 4 of them can
> actually be present in any one tuple.
>
>
> -- Jacob
And my
Po Lu wrote:
Jacob Bachmeyer 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
Po Lu wrote:
Jacob Bachmeyer writes
This is why I am arguing that we should acknowledge that the naming
conventions have, in practice, already changed to
CPU-VENDOR-KERNEL-OS-LIBCABI, with only 3-or-4-of-5 elements present
at the moment.
$ ./config.sub a-b-c-d-e
Invalid configuration
"John Ericson" writes:
> I have offered multiple times to change it to windows-mingnu or
> something else. Let's not be hung up on this, it is just making a straw
> man of the broader project of making configs that are more
> consistent.
The point is, it should not contain `windows' at all, and
On Mon, Aug 21, 2023, at 1:17 AM, Po Lu wrote:
> Jacob Bachmeyer 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
Jacob Bachmeyer writes:
> This is why I am arguing that we should acknowledge that the naming
> conventions have, in practice, already changed to
> CPU-VENDOR-KERNEL-OS-LIBCABI, with only 3-or-4-of-5 elements present
> at the moment.
$ ./config.sub a-b-c-d-e
Invalid configuration 'a-b-c-d-e':
John Ericson writes:
> I agree the GNU project is not under any such obligation, and that's
> why I proposed windows-mingw as a compromise.
Once again, what's wrong with plain mingw? Or winnt?
> It is more work for me to go make both GCC and LLVM support, but I
> rather do that than be stuck
Jacob Bachmeyer 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'
Po Lu wrote:
Jacob Bachmeyer 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
Po Lu wrote:
John Ericson writes:
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
On 8/21/23 00:39, Po Lu wrote:
John Ericson writes:
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
John Ericson writes:
> 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
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
Jacob Bachmeyer 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
Po Lu wrote:
"John Ericson" 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
"John Ericson" writes:
> If Musl, GNU Libc, and Android are all different operating systems,
> why are MSVCRT, MinGW, and Cygwin not different operating systems?
Musl is not an operating system, but Musl-based systems are distinct
from GNU and Android systems, in that they share nothing in
On Fri, Aug 18, 2023, at 8:24 PM, Po Lu wrote:
> GNU is an operating system. Musl-based systems are not GNU, so -musl
> represents a ``musl-based operating system''.
>
> > I do not think this is something to be frowned upon because "Operating
> > System.", after all, also lacks any rigorous
"John Ericson" writes:
> 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.
So let's please remove that change, and replace it with one that
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
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...
Even more important than this is the
x86_64-pc-windows-* is first and foremost a _misnomer_. The format of a
configuration triplet (or quadruplet) is set in stone:
MACHINE-VENDOR-[KERNEL-]OS.
Given that the MinGW ABI does not constitute the GNU operating system
executing on the MS-Windows kernel, and MSVC is not an operating
35 matches
Mail list logo
