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:

a

The image being built is an object library.

so

The image being built is a shared object.

dll

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.

shared

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.

g

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.

gcc

Use the GCC (gcc) compiler to compile the source. If you don't specify a compiler, the makefiles provide a default.

o

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:

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 so.403.be, the makefiles define the following C macros:

• VARIANT_so
• VARIANT_403
• VARIANT_be

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 endianness it's running under.