These all hit code paths that were not already being tested, but
produce (what appears to be) the correct canonical name without
requiring any more code changes.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Add the following entries to the tables of valid CPUs, vendors, and
operating systems:
CPUs: v810
Vendors: acorn, atari, be, ccur, commodore, digital, intergraph, rebel,
rom68k, rombug, semi, siemens, sni, stratus, tektronix
OSes: atheos, chorusos, psos, syllable, wince
Evidence elsewhere in this script, and/or in config.guess, indicates
that these are all supposed to be valid.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
It seems to me that if ‘fooco’ expands to ‘cpu-fooco-foonlyos’,
where ‘cpu’ is whatever CPU was hip at the time Fooco was making
computers, then ‘cpu-fooco’ should also expand to ‘cpu-fooco-foonlyos’,
and ‘cpu-foonlyos’ should as well, except when ‘foonlyos’ is something
generic like ‘sysv’ or ‘bsd’. Implement a bunch of cases where we
didn’t do this quite right. Probably there are more.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Handle ‘i386-nova’ as shorthand for a 4-part system name,
kernel=rtmk os=nova, instead of a canonicalized OS name with
a dash in the middle, os=rtmk-nova.
RTMK <https://rtmk.sourceforge.net/> is a microkernel.
Nova <https://www.nongnu.org/nova> is an OS written on top of that
microkernel. The short system name ‘i386-nova’ was therefore defined
to canonicalize to ‘i386-pc-rtmk-nova’, I think prior to the general
introduction of 4-part system names. ‘i386-pc-rtmk-nova’ still makes
sense under the rules for interpreting 4-part names, but nowadays the
logic for validating canonicalized name components rejects OS names
with a dash in the middle. Feeding kernel=rtmk os=nova to that logic,
instead, does the Right Thing.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
These attempt to perform normalizations that were already done by
code above this point, so they are unnecessary. There are already
test cases for these normalizations.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Normalize the names for NeXT’s operating systems consistently.
The version number bump from 2 to 3 went along with a marketing
name change from “nextstep” to “openstep”, which was being honored,
or not, depending on what shorthand you put in and what CPU you
selected (!)
Consistent with the treatment of “Solaris 1” as an alias for sunos4
and “SunOS 5” as an alias for solaris2, and also with what config.guess
appears to do on these machines (which I do not have), config.sub will
now emit CPU-next-nextstep, -nextstep2, -openstep3, -openstep4 no
matter how it was spelled on input.
These OSes historically were used with several other CPUs besides m68k
and sparc, but I think one CPU for which they have a single-component
shorthand, and one for which they don’t, is enough testing.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
A similar issue to the previous patch: make the OS default for the CPU
aliases “blackfin,” “m68knommu,” and “parisc” actually be a default
and not an override. There have been many OSes for PA/RISC. Both
blackfin and m68knommu are definitely used in bare-metal configuration
as well as with an OS. And in general, CPU aliases should behave as
much like the canonical CPU name as possible.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Fix a typo in the logic for handling the OS default for c90-cray,
causing c90-cray-[anything] to get overridden to c90-cray-unicos.
I’m not aware of any non-Unicos operating systems for the C90, but
let’s not be a pointless obstacle for anyone who wants to write one.
(For testing purposes I used Linux, because config.sub’s generic logic
accepts it in combination with any CPU whatsoever.)
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
convex-cNN and cNN-convex (where NN in 1, 2, 32, 34, 38) are supposed
to be shorthands for cNN-convex-bsd, but the code to handle them
was in the wrong switch statement, making it unreachable. Fix.
https://en.wikipedia.org/wiki/Convex_Computer says there was also a C4
machine in this product line, at least on paper, but it’s not clear to
me whether they ever shipped one.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
There is evidence elsewhere in config.sub, and in config.guess,
indicating that knetbsd-gnu, netbsd-gnu, and uclinux-gnu were
supposed to be acceptable combinations of $kernel and $os, but
they are currently being rejected. Add them to the list of
acceptable kernel-os combinations, and add test cases for them.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
config.sub had a rule that os=sunos* implies vendor=sun unless the
vendor has already been set for some other reason, but no such rule
for os=solaris*, and that meant `./config.sub sparc-solaris2` was
inconsistent with what you’d get from config.guess on that system.
Add the missing rule.
Unlike the previous patch, this changes config.sub output for some
systems still actually in use today, but hardly anything looks at
the vendor field unless the OS field is something super generic like
“bsd” or “sysv”, so I think we can get away with it.
This patch also adds tests for the mapping of ‘sunos5’ to ‘solaris2’
and ‘solaris1’ to ‘sunos4’, which is logically unrelated *except*
that some of those test cases will fail in the absence of the above
change.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
config.sub was mapping all single-component shorthands matching the
shell glob `dpx2*` to ‘m68k-bull-sysv3’, which is incorrect. Of the
four different machines once manufactured by Groupe Bull whose model
number can be abbreviated ‘dpx2something’, only two were m68k-based:
the DPX/2-200 and DPX/2-300. The DPX/2-100, on the other hand, had an
i386 CPU. And the DPX/20 was a completely different beast, released
years later and based on the POWER architecture.
I’ve chosen to keep making ‘dpx2’ map to ‘m68k-bull-sysv3’ as the
DPX/2-200 and /2-300 seem to have been the most widely used. config.sub
now understands ‘dpx2100’, ‘dpx2200’, and ‘dpx2300’ as shorthands for
‘i386-bull-sysv3’, ‘m68k-bull-sysv3’, and ‘m68k-bull-sysv3’ respectively.
It also accepts ‘dpx21xx’, ‘dpx22xx’, and ‘dpx22xx’ as equivalent to
these, but no other variations; in particular, ‘dpx2xxx’, which was in
the test suite, no longer works, as it is ambiguous.
(As far as I can tell, there weren’t actually any submodels of any of
these systems, so I could be persuaded to remove the …xx aliases.
I kept them mainly because of the test suite formerly testing dpx2xxx.)
Finally ‘dpx20’ now maps to ‘rs6000-bull-bosx’. Both the ‘rs6000’ and
‘bosx’ components of this name are debatable, but I *think* it is what
config.guess would do on this machine.
Sources for Bull DPX/2whatever history:
- https://oldskool.silicium.org/stations/bull_dpx20.htm
- https://www.feb-patrimoine.com/english/bull_dpx2.htm
- https://www.feb-patrimoine.com/english/unix_and_bull.htm
Note in particular “Que cette machine soit estampillée BULL ou IBM,
elle faisait tourner AIX (l'Unix d'IBM)” on the first of these pages,
which is why I say “bosx” is debatable…
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Several of these lists are going to be modified substantially in the
next few patches, this will make it much easier to see what is going on.
No functional change.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
With the version of shellcheck I have (0.9.0), the existing attempts
to disable SC2162, above each use of read without -r, do not work
because they are not on the line *immediately* previous to the read
command — there’s always a “saved_IFS=$IFS” line in between. Since
this script must not use read -r at all, we should just be disabling
SC2162 globally.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Ensure that the second column of testsuite/config-sub.data is
consistently indented—always to the same distance, using tabs—
and that the entire file is properly sorted. No functional change.
It might make sense to swap the two columns of this file and then
re-sort it, which would group all the aliases for a single canonical.
I think it would be easier to work with that way but I don’t want to
make that change unilaterally.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Implicit ‘int’ (e.g. ‘extern foo();’ meaning the same thing as
‘extern int foo();’) was dropped from the C standard in its 1999
edition. Twenty-five years later, free C compilers are finally
starting to make this an error by default, so let’s not use it
anymore in config.guess probe programs.
(Note: As of this writing, GCC 14 and Clang 16 are both more lenient
for ‘main() { … }’ specifically than for other uses of implicit int.
Still, the writing is clearly on the wall.)
We continue to use ‘int main() { … }’, instead of ‘int main(void) { … }’,
because these programs may be compiled by truly ancient compilers that
do not recognize the keyword ‘void’. This leaves open the possibility
of a compiler that errors by default on an empty argument list in a
function definition, which, prior to the 2024 C standard, is technically
still an “old-style” function definition; but we can worry about that
if and when it comes up.
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
Co-authored-by: Zack Weinberg <zack@owlfolio.org>
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Add support for [OpenHarmony] targets.
The `ohos` targets are available [in `LLVM`] and
documented in the [Rust target documentation].
Known targets in Rust:
- aarch64-unknown-linux-ohos
- armv7-unknown-linux-ohos
- x86_64-unknown-linux-ohos
Known targets in Clang:
- arm-linux-ohos
- aarch64-linux-ohos
- x86_64-linux-ohos
There are also some additional targets available in clang,
e.g. `liteos-ohos`, but I don't know much about those
targets, so I'm leaving `liteos-ohos` out of scope for this
patch.
[OpenHarmony]: https://gitee.com/openharmony/docs/
[in `LLVM`]: https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/OHOS.cpp
[Rust target documentation]: https://doc.rust-lang.org/rustc/platform-support/openharmony.html
* config.sub ($os == ohos*): Recognize.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (aarch64-linux-ohos): New entry.
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
ARM64E is a custom ABI for AArch64 8.3+ introducing pointer
authentication codes. While technically just an ABI, it is treated
as its own machine type, with triples in the format arm64e-*.
* config.sub (arm64e): Recognize.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (arm64e-apple-darwin20.0.0,
arm64e-apple-ios): New entries.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
This commit causes gnu-config to recognize the *-*-uefi triples.
These triples describe binaries which use the PE object file format
and UEFI calling "convention" (which is actually a family of
completely unrelated calling conventions, one per CPU architecture):
- https://uefi.org/specs/UEFI/2.9_A/02_Overview.html#detailed-calling-convention
- https://uefi.org/specs/UEFI/2.9_A/02_Overview.html#detailed-calling-convention-1
- https://uefi.org/specs/UEFI/2.9_A/02_Overview.html#detailed-calling-convention-2
- https://wiki.osdev.org/UEFI#Calling_Conventions
This is in contrast to the *-w64-mingw32 triple of GNU-EFI, which
uses the ELF format and cdecl calling convention:
- https://wiki.osdev.org/UEFI#Calling_Conventions
Because *-*-uefi uses a different object file format (everywhere)
and calling convention (everywhere except x86_32) from
*-w64-mingw32, the resulting binaries cannot be linked against each
other. This is the primary justification for introducing a new
triple.
Since gnu-config does not yet have triples for these builds, we
might as well use the same ones already selected by LLVM. It
considers uefi to be an operating system:
- https://reviews.llvm.org/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 <adam@westernsemico.com>
X-Disclaimer: This commit shall not be construed as the author's approval of the UEFI boondoggle in any way, shape or form.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
This is supported in this GCC fork. [1] It has been packaged in Nixpkgs
since 2019. [2]
Their change to `config.sub` [3] is similar, but also includes a `vc4`
-> `vc4-unknown-elf` shorthand; I don't see any reasons to add any new
legacy 1-component short-hands, so I just skipped that part.
[1]: https://github.com/itszor/vc4-toolchain
[2]: https://github.com/NixOS/nixpkgs/pull/72657
[3]: 91278afabe
* config.sub (vc4-*): Recognize.
* testsuite/config-sub.data (vc4-unknown-none-elf): New entry.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
`windows-gnu` has been used by LLVM and Rust to mean MinGW, but many
people on the mailing list object that it is in no way bona fide GNU on
Windows. Even under the interpretation of `-gnu` as a libc which LLVM
often goes with, it doesn't pass muster either because MinGW uses
msvcrt/ucrt, not any GNU libc. Arguably Cygwin, using a modified (GNU)
Newlib, is the closest thing we have to "GNU on Windows" today.
We couldn't decide on what `windows-*` should replace it, or even
whether there should be such a thing, so absent consensus it is better
to just remove it while it is still recently added and we don't need to
worry about backwards compatibility. We can always re-add it later, but
we can't do nothing now and remove it later.
This partially reverts commit 91f6a7f616b161c25ba2001861a40e662e18c4ad.
* config.sub (windows*-gnu*): Remove.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (x86_64-windows-gnu): Remove.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
ARM64EC is a custom ABI for AArch64 that allows for interoperability
with x86_64 compiled code. While technically just an ABI, it is treated
as its own machine type, with triples in the format arm64ec-*.
* config.sub (arm64ec): Recognize.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (arm64ec-pc-mingw32, arm64ec-windows): New
entries.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
config.guess says aarch64c-unknown-freebsd14.0 (cfarm240.cfarm.net,
an Arm Morello SoC, quad-core aarch64 Neoverse N1-based CPU
implementing CHERI), so let config.sub allow it.
* config.sub (aarch64c): Recognize.
* doc/config.sub.1: Regenerate.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Starting with commit afe1fa96bf32, "uname -p" from PATH is invoked in
case of FreeBSD on arm, while in other FreeBSD cases it was invoked
using a full pathname as "/usr/bin/uname -p". Fix this inconsistency
and invoke "uname -p" from PATH for all FreeBSD cases. This also allows
to test non-arm FreeBSD cases.
* config.guess (*:FreeBSD:*:*): Invoke "uname -p" from PATH.
* doc/config.guess.1: Regenerate.
* testsuite/config-guess.data (x86_64-unknown-freebsd5.2,
i586-unknown-freebsd7.0): Reintroduce the tests removed by commit
68873f3c11c6.
Here's a patch to recognize Android environments.
Such environments are "apps" with POSIX-like tools. Today, the most frequently
used one is Termux [1][2][3]; on devices with Android versions before 5.0
one can use Terminal-IDE [4][5].
config.sub already supports this environment:
$ sh config.sub armv7l-linux-androideabi
armv7l-unknown-linux-androideabi
I've built many GNU packages in this environment, with the following recipe:
CONFIG_SHELL=$PREFIX/bin/sh; export CONFIG_SHELL
CC="clang -ferror-limit=0" CXX="clang++ -ferror-limit=0"; export CC CXX
./configure --host=armv7l-linux-androideabi --prefix=$HOME/local
The Termux people have compiled or ported more than 1000 packages as well [6].
But the requirement to pass the --host parameter each time is an annoyance.
Without it, based only on the results of uname, config.guess guesses
$ sh config.guess
armv7l-unknown-linux-gnueabi
and many configuration results are wrong (because Android has many functions
in libc without declaring them in the .h files, depending on the so-called
"Android API level"), leading to many compilation errors.
With the attached patch, it produces
$ sh config.guess
armv7l-unknown-linux-androideabi
The patch does not include an addition to the config.guess test suite, since
the uname values are:
$ uname -m
armv7l
$ uname -r
4.19.127
$ uname -s
Linux
$ uname -v
#1 SMP PREEMPT Tue Apr 4 16:54:58 IST 2023
$ uname -p
unknown
which maps to armv7l-unknown-linux-gnueabi.
[1] https://github.com/termux/termux-app
[2] https://f-droid.org/en/packages/com.termux/
[3] https://wiki.termux.com/wiki/Main_Page
[4] https://en.wikibooks.org/wiki/Android/Terminal_IDE
[5] http://www.spartacusrex.com/terminalide.htm
[6] https://github.com/termux/termux-packages/tree/master/packages
* config.guess (Linux|GNU|GNU/*): Detect Android.
* doc/config.guess.1: Regenerate.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
GHC has been using a custom triple "javascript-unknown-ghcjs" for
their (non asm.js, non wasm) javascript-emitting kernel-less target.
This triple is a bit of an oddball, so the support for it is highly
restricted in order to discourage further proliferation of the
javascript "cpu" or ghcjs "operating system", which are valid only
in combination with each other.
* config.sub (javascript-*-ghcjs): Allow.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (javascript-ghcjs,
javascript-unknown-ghcjs): New entries.
Link: 6636b67023
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
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,
s390, and mmix. This commit adds test cases for this clobbering
behavior, so that unintentional changes to it will be noticed.
* testsuite/config-sub.data (microblaze-unknown-elf, mmix-unknown-elf,
s390-unknown-elf): New entries.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Instead of treating them as OSes, we treat them as their own category.
This is modeled on what LLVM does with its `ObjectFormatType` enum [1],
advancing my long-running project of trying to nudge GNU config and LLVM
towards each other, taking the best ideas of both.
Currently, my emphasis is just on code cleanup. There are just a few
tests for newly supported changes that fall out of this. But down the
road, this also opens the door to parsing configs with more than 4
components, like [2].
[1]: https://llvm.org/doxygen/classllvm_1_1Triple.html#a83e907e55fa50e093caa96a0aff96201
[2]: a18266473b/llvm/unittests/TargetParser/TripleTest.cpp (L1873C50-L1873C77)
added in
28b82bc39e
* config.sub: Save machine code format name separately from the OS name.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (arm-unknown-none-aout,
arm-unknown-none-pe): New entries.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
GNU binutils support the selection of the default MIPS subtarget via the
configuration triplet, e.g. `mips64octeon+el-unknown-linux-gnu' builds a
Linux/GNU 64-bit MIPS (n32 ABI) little-endian configuration with the CPU
set to Octeon+ by default. However `config.sub' rejects such a triplet
and indeed it only lets through a random choice of ones people submitted
changes for to support.
There is a large number of MIPS CPU configurations, 118 at the moment,
that GNU binutils know, so rather than adding them individually and then
hoping it will be kept up to date from now on accept any `mips*' pattern
for the machine part, just as we already do for a few of other targets.
* config.sub: Allow any `mips*' CPU rather than listing a choice
individually.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data: Add test cases.
On x86_64 Linux, a C compiler producing 32bit code causes the guessed
CPU to be changed to i686.
Adapt this approach for aarch64 Linux, i.e. change the guessed CPU
to armv8l when a compiler producing arm eabi code is detected.
* config.guess (aarch64:Linux:*:*): Test for the 32-bit ABI.
* doc/config.guess.1: Regenerate.
Suggested-by: David Allsopp <david.allsopp@metastack.com>
These are distinct from "ios". They are also technically Darwin, so while
something like "aarch64-apple-darwin" could be used when targeting these,
on Apple-silicon based systems there could be cases where `--host` and
`--build` have the same value, and a ./configure script may determine that
we are not cross building, causing it to try to execute test programs for
the target OS that will not run on macOS.
These are functionally equivalent to iOS, and targets with "-tvos" and
"-watchos" are already used by clang.
* config.sub (tvos*, watchos*): Recognize.
* testsuite/config-sub.data (arm64-apple-tvos, arm64-apple-tvos10.0.0,
arm64-apple-watchos, arm64-apple-watchos5.0): New tests.
* doc/config.sub.1: Regenerate.
These are not real OSes, they are object file formats. There is a
longstanding tradition of using them for embedded/freestanding
programming, so it makes sense to parse them with `kernel=none`.
(I have a WIP future patch that systematizes parsing these non-OSes a
bit more. That also opens the door to parsing a 5th component as LLVM
can do.)
This change unblocks an issue we've been having with Nixpkgs (see
https://github.com/NixOS/nixpkgs/issues/165836 for the longer version).
* config.sub (none-coff*, none-elf*): Recognize.
* testsuite/config-sub.data (arm-unknown-none-coff,
arm-unknown-none-elf, riscv64-company-none-elf): New tests.
* doc/config.sub.1: Regenerate.
In older times, MinGW (GCC toolchain with modified windows headers) was
the only free software toolchain for Windows. But now, LLVM has support
both for MinGW ABI and Microsoft's own. The distinction matters for C++
more than C.
LLVM[1], Rust[2], and other projects have taken to differentiating these
two as `...windows-gnu` vs `...windows-msvc`. I think that makes a lot
of sense, as it correctly identifiers both their commonalities and their
differences.
A lot of MinGW-supporting software, most notably GCC itself, will
presumably continue to use configs like x86_64-pc-mingw32 and
i686-pc-mingw32. That's fine; this patch doesn't normalize them away
(like LLVM does) or remove them! If and when that software wants to
support the MSVC ABI without requiring MSVC itself, they can switch to
these newer configurations.
[1]: a18266473b/llvm/unittests/TargetParser/TripleTest.cpp (L1907-L1951)
[2]: 36fb58e433/compiler/rustc_target/src/spec/mod.rs (L1255-L1271)
In 2012 the GNU Coding Standards changed to recommend quoting
'like this' or "like this" instead of `like this'.
Alter diagnostics and comments accordingly.
Use a more-consistent quoting style in config.sub diagnostics,
preferring 'like this' to "like this" as the former is more
resistant to shell metacharacters.
Note: currently, there's no detection method for linux-mlibc in
config.guess, since there's no decided way to detect mlibc.
Signed-off-by: Arsen Arsenović <arsen@aarsen.me>
* config.sub (linux-mlibc*): Recognize.
* testsuite/config-sub.data (aarch64-linux-mlibc, riscv-linux-mlibc,
x86_64-linux-mlibc): New tests.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
