Most popular Linux packages require their build system to be self-contained: packages are built on the same distribution and architecture as the one the package is supposed to be run on.

For example, dpkg package for Debian x86 is difficult to build on non-Debian system or on architecture incompatible to x86; rpm package for Fedora ARM is difficult to build on something other than Fedora or Fedora on ARM-incompatible architecture.

This is because scripts for building packages (.spec file for rpm, rules file for dpkg) are written without any provisions for cross-compilation (either cross-distro, or cross-architecture one) and without clear separation between binaries built for target system and binaries built to be run during build process (like tests, for example).

Existing solutions

As a result, in order to build a package for some distro and architecture, you need either a machine running this distro on this architecture, or some kind of virtualisation. However, these approaches have significant drawbacks.

Native build

Using a separate machine for each target distro and architecture is not feasible if you want to build your packages for several distros and several architectures: number of all combinations grow too quickly. Also, it can be too slow, especially for mobile devices: modern ARM-based computers are much less powerful than 64-bit x86-based workstations most developers use.


The same architecture

For the same architecture, but other distro, you need the target distro to be somehow isolated from the host system.

The simplest way is to use something like chroot with minimal set of packages from target distro installed. This requires root access to setup build environment and perform maintenance tasks (like upgrading target distro or installing new packages). Also, it can interfere with security extensions running on the host system (like SELinux or AppArmor).

Another solution is to use containers, like lxc or Docker. This is essentially the same as chroot with stronger isolation, and it has the same drawbacks as chroot solution.

Of course, you can use fully isolated virtual machine (kvm, xen etc.), but this solution is even more heavyweight and requires to install fully functional distribution, with system bootstrap procedure and services required for remote access to this system.

Other architecture

For other architecture, you need hardware emulation. This can be setup without root access (using qemu, for example), but it can be very slow: running fully emulated compiler for target architecture is much less optimal than cross-compiler built to run on host system natively.

Proposed solution

ldbox provides another solution for building and packaging software for linux distributions and architectures other the host one that

  • doesn't require full virtualisation,
  • doesn't require more permissions than regular user already has,
  • accelerates compilation for foreign architectures by using native cross-compiler transparently.