Packaging Cross Compiling Toolchains

= Guidelines for Cross Compilation packages =

Cross-compiling refers to the process of building software for one architecture on a different architecture. This is usually done either because the targeted platform is not powerful enough to build its own software, or because it makes development inconvenient.

Cross-compilers can be divided into two general categories:
 * Cross-compiling GCC tool-chains.
 * Other compilers.

Each category is described in the following sections.

Cross-compiling GCC tool-chains
The following guidelines apply to GCC, Binutils, glibc and other C libraries.


 * 1) Whenever possible, use the same version as the native tools.
 * 2) All package names should be prefixed with , excluding each part if it is not required. Example:
 * 3) * Cross-compilers for the ARM that uses Linux as the operating system and ulibc as the C library, should be prefixed.
 * 4) * The  is reserved to indicate that the cross-compiler is intended for a spesific target that requires some additional customization.
 * 5) * Exceptions are allowed if this deviates from common practice. Example: Tools for the AVR are usually just prefixed with . Deviation from this would break lots of peoples existing Makefiles.
 * 6) All cross-compilers should add   to   when building the toolchain. This is according to the cross-compiling guidelines in GCC's INSTALL document.
 * 7) Symlinks to the binaries in   prefixed with the cross-compiler prefix should be created in.
 * 8) Docs (man-pages, info and docs under %doc) should not be installed as they are identical to the native versions docs. Instead a README.Fedora will be installed through %doc redirecting people to the native docs.

Other compilers
For targets that do not use the GCC tool-chain for building software, no strict guidelines exist, and things therefore have to be decided on a case-by-case basis. However, the following guidelines should be good starting point:


 * 1) Try to stay close to upstream's  / . Deviating from this causes trouble, because  s for projects tend to hardcode paths and names of binaries.
 * 2) Be as FHS compatible as possible, except when it breaks 1.
 * 3) Avoid generic file names. If a package f.ex. wants to install a binary names   in , the binary should be moved to  , and symlink with a   prefix should be created in