Recognized variant names

You can combine variant names into a compound variant, using a period (.), dash (-), or slash (/) between the variants.

The common makefiles are triggered by a number of distinguished variant names:

The image being built is an object library.
The image being built is a shared object.
The image being built is a DLL; it's linked with the -Bsymbolic option (see ld in the Utilities Reference).

If the compound variant doesn't include a, so, or dll, an executable is being built.

Compile the object files for .so use, but don't create an actual shared object. You typically use this name in an a.shared variant to create a static link archive that can be linked into a shared object.
Compile and link the source with the debugging flag set.
be, le
Compile and link the source to generate big- (if be) or little- (if le) endian code.
Use the GCC (gcc) compiler to compile the source. If you don't specify a compiler, the makefiles provide a default.
This is the NULL variant name. It's used when building an image that doesn't really have any variant components to it (e.g., an executable for an x86 CPU, which doesn't support bi-endian operation).

Variant names can be placed in any order in the compound variant, but to avoid confusing a source configuration management tool (e.g., CVS), make sure that the last variant in the list never looks like a generated file suffix. In other words, don't use variant names ending in .a, .so, or .o.

The following table lists some examples:

Variant Purpose
g.le A debugging version of a little-endian executable. A big-endian version of a shared object. A user-defined "403" variant for a big-endian system.
Note: The only valid characters for variant names are letters, digits, and underscores (_).

In order for the source code to tell what variant(s) it's being compiled for, the common makefiles arrange for each variant name to be suffixed to the string VARIANT_ and have that defined as a C or assembler macro on the command line. For example, if the compound variant is, the makefiles define the following C macros:

Note that neither VARIANT_be nor VARIANT_le is defined on a CPU that doesn't support bi-endian operation, so any endian-specific code should always test for the C macros __LITTLEENDIAN__ or __BIGENDIAN__ (instead of VARIANT_le or VARIANT_be) to determine what endian-ness it's running under.