[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Weird behaviour about system types

From: Zack Weinberg
Subject: Re: Weird behaviour about system types
Date: Thu, 4 Feb 2021 11:50:19 -0500

Sorry for the blank reply, I misclicked.

> On Thu, Feb 4, 2021 at 11:27 AM Sébastien Hinderer 
> <> wrote:
> > checking build system type... x86_64-pc-linux-gnu
> > checking host system type... aarch64-unknown-linux-gnu
> > checking target system type... aarch64-unknown-linux-gnu
> >
> > I am okay with the first line but to absolutely not understandthe second
> > and third line. Why do the host and system types contain an "unknown"
> > string?

GNU canonical system identifiers are defined as 3- or 4-tuples: either
CPU-COMPANY-OS or CPU-COMPANY-KERNEL-LIBC.  'pc' and 'unknown' are
both filler words inserted in the COMPANY field when config.sub has
nothing more meaningful to put there.

The COMPANY field was more useful many years ago, when lots of
different Unix vendors were putting out workstations based on the
MC68020 -- 'm68k-apollo-sysv' and 'm68k-bull-sysv' for instance are
distinguished only by COMPANY.  Nowadays it's pretty much vestigial,
but we have to keep it around for compatibility with all the logic
that expects there to be at least three dash-separated fields in

> > Since I gave the --host=aarch64-linux-gnu arguemnt, I expected this to
> > be the canonical system type. And also, I thought the target system type
> > would default to the user-provided host system type, which does not seem
> > to be the case.

`aarch64-linux-gnu` is a *non-canonical* shorthand system identifier.
$host_alias is always set to the *canonical* system identifier, which
is computed from what you give as the argument to --host by passing it
through `config.sub`.

You did not give a --target option, so $target_alias defaults to
$host_alias, and both are in canonical form.

In summary, everything is working as intended.  You do not need to
change how you are running configure.  (You do, however, need to make
sure that any `case $host_alias in ... esac` blocks in your configure
script expect $host_alias to be in canonical form, e.g. `case
$host_alias in (aarch64-linux-gnu) ... ;; esac` will never execute the
... code, it needs to be (aarch64-*-linux-gnu) instead.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]