- When cross-compiling Snapcraft implicity installs architecture-specific packages for gcc and libc, internally called cross-build-packages, for
example gcc-arm-linux-gnueabihf and
libc6-dev-armhf-cross when building for armhf on a different architecture.
- There’s a discussion under way to support on selectors in build-packages to list different packages conditionally which only exist for a specific architecture.
Problem: packages for the target architecture
What’s currently missing is support for multi-arch packages installed for the target architecture rather than the host architecture. When cross-compiling for example from amd64 to armhf
build-packages: [libglib2.0-dev] will install amd64 binaries that can’t be linked to an armhf target binary. What’s actually required is the same package, but built for the target architecture, armhf. Snapcraft needs to learn how to transparently install packages for the target architecture.
Get build-packages for the correct architecture.
Note: no changes to YAML or plugin API involved.
Implementation: leveraging multi-arch internally
I started working on this some time ago with the purpose of using C libraries from build-packages from Go. But it’s proven difficult to review so this post is meant to facilitate discussion of the implementation. Note that all of the following is Debian-specific: support for multi-arch on Fedora would use different package names, different syntax, different host setup and other tools, behind the scenes.
- in Debian multi-arch syntax
:armhf specifies a package for the target-architecture,
:native specifies a package from the host architecture - this is very simplified, but basically these need to be added internally
apt-get build-dep can be used, provided the host has source packages configured, to figure out the multi-arch equivalent of a set of packages - it’s shown to be difficult to handle as a tool because errors can be ambiguous and difficult to parse (including incompatible syntax of the form
libpkg2=3:0.4-0ubu5:armhf rather than
libpkg2:armhf=3:0.4-0ubu as understood by dpkg/ apt)
- Python APT bindings understand arch suffixes but have no equivalent of
I need libglib2.0-dev for cross-compiling
To make any of this work the host needs to be setup beforehand, which in the case of cleanbuild can’t be done manually.
- The architecture needs to be registered via
dpkg --add-architecture armhf
/etc/apt/sources.list* requires package sources with
[arch=armhf] to pull in foreign-arch packages