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.