Announcing: `cross`, "zero setup" cross compilation/testing for 13 targets


#1

Hello again, Rustaceans.

I’m here to announce yet another drop-in Cargo replacement: cross.

With cross build you can cross compile your crate to any of these 13 targets without having to install a cross toolchain or cross compiled libraries on your host system, or having to manually invoke rustup target add.

cross build will provide the cross compilation environment, a Docker image, that produces the most portable binary possible (i.e. that has the lowest glibc version requirement possible). This environment also includes the latest OpenSSL, already cross compiled for the target, so you can actually cross compile a crate that depends on the openssl crate (like Cargo!) for e.g. ARM with a single cross build command.

Even cooler is the cross test command, which tests your crate for the given target. That’s right, cross will cross compile your tests for e.g. PowerPC and then run them on your x86_64 machine using QEMU under the hood. QEMU doesn’t even need to be installed on the host system!

cross works on x86_64 Linux machines, which means you can use it with Travis to continuously test your crate for a variety of architectures. Here’s a sample .travis.yml file to get you started.

The list of supported targets will only continue to grow. Keep an eye on cross. :slight_smile:


#2

Given the focus of the project, I’m kind of surprised you support x86_64-unknown-linux-musl but not i686-unknown-linux-musl and armv7-unknown-linux-gnueabihf but not arm-unknown-linux-gnueabi.

(I use i686-unknown-linux-musl via rustup target add to ensure my builds will also work on the old 32-bit machines I have kicking around and, for historical software compatibility reasons, my OpenPandora is arm-unknown-linux-gnueabi despite being an ARMv7 device.)


#3

I basically just cooked started working on this thing three days ago and went for architecture “breadth” rather than “depth”: 12 of the 13 targets have different architectures (!). The 13th is the first non-glibc / musl target and it happens to be x86_64 (and just landed today). Give it time and more targets will pop up :wink:.

FWIW, arm-unknown-linux-gnueabi* is easy to get wrong. Most people will try to use Ubuntu’s/Debian’s gcc-arm-linux-gnueabi* toolchain with it but that toolchain targets ARMv7 and the Rust target is ARMv6. This results in binaries that SIGILL when executed on ARMv6 devices. Needless to say, I want to get that one right :smile:.


#4

I’m really excited about this project. Between xargo, cross, and dinghy we’ll soon have very good build/test support for a large number of cross-compile cases.

It would be great if we could do Rust’s own CI with cross. Solve that problem once for everyone.

It seems like cross could probably do Android, if you can work out the license issues.

It could probably also do Windows, GNU with MinGW, MSVC with Wine. Maybe OS X with a custom built clang.

It’ll probably all more-or-less work on Windows too with Docker on Windows.


#5

Fair enough.

In my case, I know it works for the OpenPandora but I initially just had to trial-and-error my choice on the Rust side because all I knew about the cross-compiling GCC toolchain I’d been provided with was that it prefixed its commands with arm-none-linux-gnueabi-, I needed Rust to produce non-hf (softfloat) binaries, and there was no non-hf armv7 target offered by rustup.

(I normally program in managed languages like Python, so, if I could at all avoid it, I didn’t want to have to learn how to compile my own crossbuild toolchain from scratch before I could even get hello world cross-compiling.)