rg/D131594
* config.sub (*-*-uefi): Recognize.
* testsuite/config-sub.data (i686-unknown-uefi, x86_64-unknown-uefi,
aarch64-unknown-uefi): New entries.
Signed-off-by: Adam Joseph
X-Disclaimer: This commit shall not be construed as the author's approval of
the UEFI boondoggle in any way, sha
As mentioned in my reply to Ryan,
Quoting Adam Joseph (2023-10-26 18:33:43)
> @@ -1859,6 +1866,8 @@ case $kernel-$os-$obj in
> # None (no kernel, i.e. freestanding / bare metal),
> # can be paired with an machine code fi
rg/D131594
* config.sub (*-*-uefi): Recognize.
* testsuite/config-sub.data (i686-unknown-uefi, x86_64-unknown-uefi,
aarch64-unknown-uefi): New entries.
Signed-off-by: Adam Joseph
X-Disclaimer: This commit shall not be construed as the author's approval of
the UEFI boondoggle in any way, sha
Quoting Alfred Persson Forsberg (2023-10-19 11:55:40)
> * config.sub (*-linux-llvm): Recognize.
> * doc/config.sub.1: Regenerate.
> * testsuite/config-sub.data: Add x86_64-linux-llvm.
Looks good to me; however, one question. I assume this triple covers llvm-libc
fullbuild mode:
Quoting Po Lu (2023-08-24 21:18:13)
> People, the nature and widespread use of config.* precludes any efforts
> aimed at ``rethinking'' the tuples they accept and generate.
+1
Quoting Zack Weinberg (2023-09-10 17:52:46)
> My suggested place to draw the line is, if you reasonably need a
> cross-compiler targeting A to be different from a cross-compiler targeting B,
> then the distinction between A and B can go in the canonical system name; if
> you don't, then it
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
Quoting Zack Weinberg (2023-08-18 04:42:32)
> On Thu, Aug 17, 2023, at 8:34 PM, Po Lu wrote:
> > ... such blunders should be ignored, or at least normalized...
>
> Even more important than this is the principle that config.sub canonical names
> are *never* changed, even if they are wrong according
GHC has been using a custom triple "javascript-unknown-ghcjs" for
their (non asm.js, non wasm) javascript-emitting kernel-less target.
https://gitlab.haskell.org/ghc/ghc/-/commit/6636b670233522f01d002c9b97827d00289dbf5c
This triple is a bit of an oddball, so the support for it is highly
GHC has been using a custom triple "javascript-unknown-ghcjs" for their (non
asm.js, non wasm) javascript-emitting kernel-less target.
https://gitlab.haskell.org/ghc/ghc/-/commit/6636b670233522f01d002c9b97827d00289dbf5c
This triple is a bit of an oddball, so the support for it is highly
While reimplementing config.sub for use in a situation where no bash
interpreter was available, I discovered several oddities about
config.sub's behavior.
One such oddity was the fact that an explicitly-provided vendor will
be clobbered by the inferred vendor for three cpu types: microblaze,
While reimplementing config.sub for use in a situation where no bash
interpreter was available, I discovered several oddities about
config.sub's behavior.
One such oddity was the fact that an explicitly-provided vendor will
be clobbered by the inferred vendor for three cpu types: microblaze,
12 matches
Mail list logo
