Cross-compilation is the idea of building executable code for a platform with different specifications than the one on which the compilation is conducted. Engineers working on embedded systems often develop software on one platform—for example, a powerful workstation—and deploy it on another, such as single-board computers on a robot. Development machines are frequently x86-based, whereas robots typically incorporate Arm-based processors.
Although simple scripts may run smoothly across multiple chip architectures without special build considerations, this is not the case with complex applications with several platform-specific dependencies and configurations. For such software, when the build platform and the robot have different chip architectures, developers must cross-compile applications for the target machine.
In this article, we will explore the existing ecosystem around snaps, a popular mechanism for packaging and deploying Linux applications. And we will present Snap xCompile, an open source tool that makes cross-compiling snaps an easy one-step process.
What are snaps?
Snap is a packaging framework for creating containerized applications that can run seamlessly on any Linux-based operating system. Snapping an application rolls up all its software together with any dependencies into a single portable object that can be transferred across devices. This packaging methodology does end up increasing application footprint, but it has the benefit of increased reliability by being immune to breaking changes in dependencies upstream.
Two terms that frequently appear when working with snaps are snapd and snapcraft. Snapd is the background service—or daemon—that manages and maintains installed snaps, and is a core dependency of the snap ecosystem. And snapcraft is the command-line tool used for building snaps and, optionally, uploading them to a central repository for distribution.
Snapcraft handles most common scenarios effectively, but it does not support cross-compilation out-of-the-box. Attempting to build snaps on Docker images of the target system also fails due to snapd, a dependency for snapcraft, requiring systemd, which is usually disabled in Docker containers to enhance security and isolation.
Although a few documented workarounds exist to bypass security controls and enable systemd, these solutions impose additional setup and configuration requirements on the user. Besides, we found snapd to behave unstably with such setups—particularly for Arm-based machines—when host and container chip architectures diverged, as is often the case when cross-compiling for embedded systems.
Snapcraft does offer the ability to build snaps remotely for a variety of target architectures, but this approach uploads your code to Launchpad and makes it publicly available. This renders it an unviable option for teams that are not yet ready to open source their code, or those that prefer keeping their code private. Such organizations need a mechanism that allows developers to cross-compile snaps while keeping their code private. Enter Snap xCompile.
What is Snap xCompile?
Snap xCompile is a command-line tool for cross-compiling snaps for x86-64 and Arm64 targets without exposing any aspects of the source code to the public. This tool uses Amazon Web Services (AWS) to securely and privately package application source code for a chosen target architecture.
With Snap xCompile, a single command spins up a remote server hosted on AWS, gathers all relevant applications files with their dependencies, runs the snapping process, and fetches the completed snap to the host workstation.
The tool handles all aspects of AWS infrastructure provisioning while keeping to the principle of least privilege to maintain a high level of security for the application code. And because the snapping process runs entirely on AWS, compilation can be carried out from any terminal regardless of the workstation’s hardware and software configurations.
The result is a seamless one-step method to cross-compile snaps that requires no configuration effort.
Now let’s walk through the tool in action by snapping a simple Hello World ROS application for an Arm64 target. The build will run entirely on the cloud, independent of the workstation’s hardware configuration.
To learn more about why snaps are a valuable component for the ROS ecosystem, read “Deploying ROS applications as Snaps with AWS IoT Greengrass 2.0.”
For this walkthrough, you should have the following prerequisites:
Step 1: Set up the tool.
- Download the project to your local system.
- Give execution permission to the shell script.
The tool expects two parameters during invocation:
- –source: Path to the application to be snapped
- –arch: Architecture of the target system
Snap xCompile currently supports snapping for x86_64 and Arm64 targets.
Step 2: Run snapping.
- Snap the example ROS project for the desired target architecture.
This step will take several minutes to finish.
- The finished snap will be located in your working directory once the script completes.
Step 3 (optional): Deploy and test.
- Transfer the finished snap to the target system.
- Install the snap, replacing <FILENAME> with the snap’s name from the previous step:
- Run the
launchcommand declared for the snap to see the application working.
The ability to cross-compile deployable assets is key to development workflows in IoT, robotics, and other embedded systems. With Snap xCompile, we now have a mechanism to build snaps for x86_64 and Arm64 machines easily and securely using remote AWS build farms. We no longer need to transfer code manually, build Docker images, write special configuration files, or handle resource provisioning to obtain a cross-compiled snap. Instead, specify a target architecture and provide the path to the application code, and the tool produces the desired snap—all while prioritizing the privacy and security of both the source code and the cloud infrastructure.
Try snapping a project today on your laptop with Snap xCompile and have snaps working effortlessly on embedded boards like Raspberry Pi, Jetson Nano, Odroid, and Beagle Board.