This document describes the design of cross-compiling support in exherbo, focussing mainly on what exheres authors should be familiar with. For background on the motivation and design consult multiarch design.
The cross compilation support in exherbo is limited to the C family of languages. That is, it does not apply to the scripting set of languages (e.g. python, Ruby, perl) which will continue to be supported by multibuild to support the multiple versions. However, this mechanism supersedes the C class of multibuild.
This section intends to expound the terms that are used throughout this document.
build
build refers to the host on which the compilation is taking place.
target
target refers to the environment that the binaries that are generated will execute on. This may be a “multilib” for the build, or it may be a foreign architecture.
tool-prefix
In order to support multiple versions of the same tools residing on the host, all compilation related tools (collectively called the toolchain), are prefixed with the target that they are meant for. This prefix may or may not fully match the target. That is, tool-prefix should not be assumed to be the same as target. As an example, you could have a target of armv7-unknown-linux-gnueabi with a tool-prefix of armv7-arm-linux-gnueabi.
Each host configuration is effectively a target. The target is specified by the canonical target triple as specified by GCC.
Currently, we support the following targets:
- i686-pc-linux-gnu
- x86_64-pc-linux-gnu
- armv7-exherbo-linux-gnueabiAdding additional targets requires that a full system set is bootstrapped and available before we can add support for a new target.
These are also listed in the profile in CROSS_COMPILE_TARGETS.
Users can select the targets that they wish to build a package for. Any run, post, and build+run dependencies for the package must also be built for the same targets. This is necessary to provide the supporting libraries for the package.
Most packages are easy to update to support cross compilation. In most cases, it involves the removal of the multibuild_c option. Furthermore, any use of hardcoded paths needs to be adjusted to allow parallel installation of multiple targets.
There are options set by the options.conf for the profile currently in use which can have effects on exheres.
targets:*
The targets suboption enumerates the toolchain target hosts. Each value is an environment where the generated libraries and binaries may run. These indicate which target compiler(s) to build when building the toolchain. If x86_64-pc-linux-gnu compiles for itself, targets:x86_64-pc-linux-gnu is set, and can be used by the exheres. x86_64-pc-linux-gnu decides to compile for i686-pc-linux-gnu, and would have targets:i686-pc-linux-gnu set.
These sub options are reserved for toolchain packages; most packages should just use exhost to query information about the target environment. Packages such as pkg-config are considered to be part of the toolchain.
Extending support to the remaining packages requires that the profile for the host is updated to add the new target to the CROSS_COMPILE_TARGETS list in profiles/make.defaults. metadata/options/descriptions/hosts.conf should be updated with a description of the suboption. This will enable building the toolchain packages for the new target. Once the toolchain is bootstrapped, you will need to cross-compile the system stage to get proper support for the new target.
These autoconf macros require rebuilding configure using autotools.exlib for cross-compiling to work:
AC_FUNC_CHOWN, AC_FUNC_GETGROUPS, AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK, AC_FUNC_MALLOC, AC_FUNC_MMAP, AC_FUNC_REALLOC, AC_FUNC_STRCOLL (newer/unreleased autoconf improved them, and we ship that patch on autoconf)
They can be checked for with:
autoconf --trace=${macro} 2> /dev/nulleconf now passes --datarootdir=/usr/share to configure by default. If configure was generated by an older autoconf version this might cause it to fail. This can be fixed by rebuilding configure using autotools.exlib or by passing --hates=datarootdir to econf, depending on if the package actually needs datarootdir to be set.
Some packages use the value of prefix for finding data. Although datadir is an alternative, as long as the package correctly differentiates between prefix and exec-prefix, this can be made to work. In these cases, you can specify --prefix=/usr --exec-prefix=/usr/$(exhost --target) --includedir=/usr/$(exhost --target)/include to correct the paths the package uses. Note that the includedir must be reset as the default value uses prefix.
Packages using intltool may require intltoolize --force --automake being executed during src_prepare in order to install the translation data into the host independent location rather than into the host dependent location.
Packages which use AC_PATH_PROG to find pkg-config are unable to find a valid pkg-config. This can be remedied by modernising the use of autotools and using the PKG_PROG_PKG_CONFIG macro to properly detect pkg-config. Note that this must be invoked prior to the first invocation of the PKG_CHECK_MODULES macro as the result is used in the macro.
If you get the error message “undefined reference to `rpl_malloc’”, it’s autotools striking back. To fix it, it’s normally enough to run eautoreconf.
Copyright 2015 Saleem Abdulrasool