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 arch-os-libc-custom_tag-, excluding each part if it is not required. Example:
   • Cross-compilers for the ARM that uses Linux as the operating system and ulibc as the C library, should be prefixed arm-linux-ulibc-.
   • The custom_tag is reserved to indicate that the cross-compiler is intended for a spesific target that requires some additional customization.
   • Exceptions are allowed if this deviates from common practice. Example: Tools for the AVR are usually just prefixed with avr-. Deviation from this would break lots of peoples existing Makefiles.
3. All cross-compilers should add --prefix=/usr/arch-os-libc to ./configure when building the toolchain. This is according to the cross-compiling guidelines in GCC's INSTALL document.
4. Symlinks to the binaries in /usr/arch-os-libc-custom_tag/bin/ prefixed with the cross-compiler prefix should be created in /usr/bin.
5. 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 Makefile/configure. Deviating from this causes trouble, because Makefiles 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 cc in /usr/bin, the binary should be moved to /usr/libexec/%{name}, and symlink with a %{name - prefix should be created in /usr/bin/