aboutsummaryrefslogtreecommitdiffstats
How to cross-compile skalibs

skalibs
Software
skarnet.org

How to cross-compile skalibs

There are three issues in the world of cross-compilation:

  • support for parallel builds: the source directory must be read-only and each build process must have its own build tree.
  • support for compiler options: to specify the target architecture, the header and library files that should be used, etc.
  • build-time tests performed on the build architecture are invalid if the target architecture is different.

Support for parallel builds

skalibs does not support out-of-tree builds at the moment, but since the source code tree is small, it's not costly to duplicate it to perform parallel builds. If the source code tree grows significantly larger, out-of-tree build support will be considered.

Support for staging

The skalibs Makefile, as well as every other skarnet.org package's Makefile, supports the DESTDIR convention for staging. To install skalibs under a stage fake root:

  • Give the options you need to ./configure. The arguments to the --prefix, --libdir and similar options must be the valid paths for run-time.
  • To install the software, run make install DESTDIR=stage.

Support for build-time options and bypassing target execution tests

skalibs uses a standard ./configure && make && make install process, and cross-compiling build-time options can be given on the ./configure command line.

skalibs performs a certain number of build-time tests, to collect behaviour information on the target architecture. Most of these tests work when cross-compiling, because they only involve characteristics of the target that the cross-toolchain knows at build time; but some actually require code execution on the target, and so they cannot be performed when cross-compiling. For those, you have to manually give a special option to configure, to tell the build system what the behaviour of the target architecture is. The option is of the form --with-sysdep-key=value, where key is the name of the sysdep (i.e. the element of target behaviour that is being tested), and value the associated value, most of the time yes or no.

At all times, ./configure --help provides the list of sysdeps you need to provide a --with-sysdep-* option for. As of skalibs-2.14.0.1, there are two sysdeps in this case:

  • devurandom: yes if the target has a valid pseudorandom generation device in /dev/urandom, and no otherwise.
  • posixspawnearlyreturn: yes if the target has a broken posix_spawn() implementation that can return before the child has successfully exec'ed. That happens with old glibcs and some virtual platforms.