8.3.6 Canonical system types / Manual Configuration

A few kinds of features can’t be guessed automatically by running test
programs. For example, the details of the object-file format, or
special options that need to be passed to the compiler or linker.

Autoconf provides a uniform method for getting a canonical name for
the system type, which an Autoconf-generated configure
script can base its decisions on. (This saves you from using ad-hoc means
to determine the system type, such as having configure check
the output of the uname program, or looking for libraries that
are unique to particular systems.) A canonical name is called a
target triplet, and has the form:
‘cpu-vendor-os’, where os can be
‘system’ or ‘kernel-system’

Whenever you’re tempted to use this feature it’s worth considering
whether some sort of probe would be better. New system types come along
periodically or previously missing features are added. Well-written
probes can adapt themselves to such things, but hard-coded lists of
names can’t. Here are some guidelines,

Availability of libraries and library functions should always be checked
by probing.

Variant behavior of system calls is best identified with runtime tests
if possible, but bug workarounds or obscure difficulties might have to
be driven from the system type.

Assembler code is inevitably highly CPU-specific and is best selected
according to ‘$host_cpu’ (see Getting System Types).

Assembler variations like underscore prefix on globals or ELF versus
COFF type directives are however best determined by probing, perhaps
even examining the compiler output.