* config.guess (i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*): Use the
isainfo(1) command to guess what kind of system we have. Running
isainfo -b returns either "32" or "64".
that is executed via eval, with a POSIX shell function.
* Makefile (shellcheck): Ignore SC2039 diagnostics ("In POSIX sh,
RANDOM is undefined") and SC2172 ("Trapping signals by number is
not well defined. Prefer signal names").
"mint" and "clix".
I got rid of this forcing, as it can hide an error from the user and
is unlike how other OSes are handled. I added fallbacks for clix (MiNT
already had some) such that at least the following stil work:
$ ./config.sub clipper-clix
clipper-intergraph-clix
$ ./config.sub m68k-mint
m68k-atari-mint
$ ./config.sub mint
m68k-atari-mint
"clix" (as opposed to "nonsense-clix", ie. with at least one "-"
before) never worked, so I didn't add a short-hand to make it work
like "mint".
Signed-off-by: Ben Elliston <bje@gnu.org>
I'm not sure why this was originally added. It's certainly not needed
anymore because the OS will never be duplicated onto the send of the
`basic_machine`. If the user passed `unknown` or no vendor, this will
already be filled in. If they passed something more specific, it's
customary to respect that.
Signed-off-by: Ben Elliston <bje@gnu.org>
"wrs" is just a vendor that can be handled with all the other vendor
exceptions for two-component cases. `wrs) os=vxworks` can instead be
put with the other OS defaults down below.
Signed-off-by: Ben Elliston <bje@gnu.org>
Instead of just catching manufacturers as OSes across the board, catch
them just as the second of two components. This prevents nonsense
like:
$ ./config.sub amd64-unknown-ibm
x86_64-unknown-ibm-aix
Signed-off-by: Ben Elliston <bje@gnu.org>
$HOST_CC and $CC being undefined by using ${var-} style expansion.
(*:NetBSD:*:*): Likewise for $abi.
* testsuite/config-guess.sh: Run config.guess under `sh -eu'.
More detail from the patch author:
Currently there are number of aliases that expand both on their own
and as part of multi-component configurations. For example:
$ ./config.sub 386bsd-linux
i386-pc-bsd
This change moves all of those to just trigger on a single field
branch, preventing their matching as part of larger components:
$ ./config.sub 386bsd-linux
Invalid configuration `386bsd-linux': machine `386bsd' not recognized
This should increase correctness and avoid needless work in the common
case (as many of these are very, very old).
I was very conservative in deciding which patterns were such single
component aliases, as this does make config.sub less forgiving than
before. My criteria for patterns in this `case $basic_machine` were:
- the pattern doesn't contain any `-`
- the pattern doesn't contain any `*`
- `os` was assigned in the match body
- basic_machine wasn't essentially left as is.
The first rule is simple: if it contains a `-` it's not a
single-component pattern. The second rule is because any
`$basic_machine` pattern with an asterisk (`*`) could conceivably
match a two component string, even if the actual code strongly
signaled that was not the intent. The third rule was to indicate no
`os` was expected, as it is valid to omit a vendor in the two
component case so `basic_machine` is just one component without being
the entire configuration.
The 4th and last rule is the trickiest. If the basic_machine was left
as is, or appended with a vendor, I considered the pattern less of an
alias and more a defaulting of a canonical or near canonical
name. This seemed like a "higher quality" short-hand and thus one that
is valid as part of a larger config. Instead of just hard-assigning
`os`, however, I changed it to default `os` with:
os=${os:-DEFAULT}
so as to respect any more information the user passed. This gives us
more pleasant absurdities like:
$ ./config.sub j90
j90-cray-unicos
$ ./config.sub j90-linux
j90-cray-linux-gnu
rather than:
$ ./config.sub j90-linux
j90-cray-unicos
Signed-off-by: Ben Elliston <bje@gnu.org>
