We've been trying to debug some musl test issues, but we aren't certain if they're QEMU bugs or not since musl should be compileable on x86_64-linux for i686 and x86_64 architectures. cross doesn't output anything specific specifying when QEMU or Docker is being used, though Docker can be inferred from stdout. Having both of those output during a run would be quite useful.

When the Docker daemon has user namespace enabled, the following will fail

• Reading/writing to bind mount volumes
• --privileged flag

The fix is as simple as adding --userns=host to the docker command. BUT this will break on older Docker client versions that do not support this. I can probably fix this easily, but I am not sure how I should proceed.

EDIT: I suggest this: Use a lazy_static or something similar to do a docker engine version check. (docker version --format '{{.Server.APIVersion}}') Then if the semver is newer than 1.24, we automatically add the flag --userns=host.

I noticed that cross clears all environment variables when building a project with Docker. This breaks some build scripts and code that uses the env! macro.

I'd be very interested in an OpenBSD target :)

tokio-rs/mio#593

Trying to build a Rust project that uses C++ (via gcc-rs) on one of the musl targets fails with "musl-g++ not found". It would be neat if this combination just worked as well as C++ on other targets.

@japaric thanks for this awesome project!!
I was just wondering how some one should go about adding additional libraries that need to be linked against. Some projects like https://github.com/plietar/librespot require additional dependencies such as portaudio19-dev and maybe some others. I was just wondering what is the appropriate method for adding these into cross so that the project builds correctly.

Currently you have to run the command with RUST_BACKTRACE=1. This could possibly be a set flag/config setting for cross for debug.

I haven't been able to compile it with musl-gcc.

$ bash /openssl.sh 1.0.2j linux-elf musl- -static
/usr/bin/ld: skipping incompatible ../libssl.a when searching for -lssl
/usr/bin/ld: skipping incompatible ../libssl.a when searching for -lssl
/usr/bin/ld: cannot find -lssl
/usr/bin/ld: skipping incompatible ../libcrypto.a when searching for -lcrypto
/usr/bin/ld: skipping incompatible ../libcrypto.a when searching for -lcrypto
/usr/bin/ld: cannot find -lcrypto
/usr/bin/ld: skipping incompatible /usr/local/lib/libc.a when searching for -lc
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status

this would save us a docker call

the downside is that this requires sudo / root privilege

Right now on macOS host when target is not for macOS cross simply does nothing and calls cargo directly. But with Docker for Mac running it should be possible to cross compile to all targets that cross supports using docker.

Hey, great work.

I was wondering if it is possible to support the various *BSDs as part of the platforms? I've definitely had issues with Mio breakage.

for these targets

• mips-unknown-linux-gnu
• mips64-unknown-linux-gnuabi64
• powerpc64-unknown-linux-gnu

I have no idea why. This doesn't even involve QEMU.

cc @alexcrichton. Any tip on how to debug a build scripts that hangs/blocks? There's no output file so I can't inspect the stdout/stderr of the build script.

Will this help me compile a rust binary on my Mac that I want to distribute and run on an Ubuntu server?

This looks really cool!

There's a nice trick with musl-libc, where you can build a 100% static Rust executable that works on any distro with a reasonably modern kernel. It's also more-or-less possible to make this work with static OpenSSL. For an example, see https://github.com/emk/rust-musl-builder.

Is there any support for doing something like this with cross? If so, I'd be happy to retire rust-musl-builder and point people at cross!

if there isn't one at the root of the Cargo project.

We have migrations that we run with the build script, and we want to check if Travis is installed as that would apply whether or not migrations should be run by the build script.

I didn't see any listed iOS support. I thought that I would open an issue for it.

I recently got Mio running iOS CI on Travis. It isn't super generalized, but some of the insights that I discovered could be useful in figuring out how to generalize it.

The iOS CI script is here: https://github.com/carllerche/mio/blob/master/ci/run-ios.sh

The difficulty lies in the fact that a process on iOS must start up a coca application* within 20 seconds or the OS will kill the process. Even more fun is that the iOS application must run on the main thread. This wouldn't be a huge deal except that the rust test runner is pretty limited and also starts on the main thread.

The insight that I had is that you can specify an alternate entry point symbol during the link phase. So, I build a little iOS harness that starts the app then runs the Rust tests.

This could probably be generalized and included in cross.

• I am not an iPhone dev, so I may be misunderstanding or using wrong terminology.

I have this Cargo.toml:

[package]
name = "play-youtube"
version = "0.1.0"
authors = ["LEGOlord208 <[email protected]>"]

[dependencies]
# dependencies here

[target.x86_64-unknown-linux-gnu]
image = "play-youtube"

I have the play-youtube docker image with the latest tag.

Using cross build --release -v --target x86_64-unknown-linux-gnu,
I just see that it doesn't use the image - AND it prints
warning: unused manifest key: target.x86_64-unknown-linux-gnu.image

Help?

EDIT: s/cargo build/cross build

Supporting cross compilation from unix to *-pc-windows-gnu is easy with the mingw toolchain, which happens to include .libs for the system libraries.

It seems that Cargo is not passing -C linker=foo to rustc for that particular subcommand.

We can get a little further by setting QEMU_CPU=something in the environment but then instead QEMU segfaults instead of throwing an error.

Should https://github.com/snipsco/dinghy be used?

Support for testing android binaries that depends only on libc was added in #132.

We should add support to test android binaries in the android emulator. See #132 for a brief discussion of the issues of distributing the android emulator.

I'm not entirely sure what happened, but cross can't compile my code anymore, even though nothing changed in either my code, the rust compiler or cross. I assume Travis themselves broke something.

https://travis-ci.org/CryZe/livesplit-core/jobs/245407142#L596

  = note: WARNING:root:(Emscripten: unknown: [Errno 13] Permission denied, clearing cache)
          CRITICAL:root:Could not verify LLVM version: [Errno 13] Permission denied
          CRITICAL:root:fastcomp in use, but LLVM has not been built with the JavaScript backend as a target, llc reports:
          ===========================================================================
          (no targets could be identified: [Errno 13] Permission denied)
          ===========================================================================
          CRITICAL:root:you can fall back to the older (pre-fastcomp) compiler core, although that is not recommended, see http://kripken.github.io/emscripten-site/docs/building_from_source/LLVM-Backend.html
          INFO:root:(Emscripten: Running sanity checks)
          CRITICAL:root:failing sanity checks due to previous fastcomp failure

I'm trying to use error-chain in one of my project with cross, but it seems that the version of glibc in the ubuntu 12.04 base images is not sufficient for one of the error-chain dependencies called backtrace. Is there a specific reason for the Dockerfiles to base off of ubuntu 12.04 or can they be upgraded to 14.04 or 16.04?

This is the error I currently get:

Build failed, waiting for other jobs to finish...
error: failed to run custom build command for `backtrace v0.3.0`
process didn't exit successfully: `/target/debug/build/backtrace-4d922e79d0b3f0f4/build-script-build` (exit code: 1)
--- stderr
/target/debug/build/backtrace-4d922e79d0b3f0f4/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.17' not found (required by /target/debug/build/backtrace-4d922e79d0b3f0f4/build-script-build)
/target/debug/build/backtrace-4d922e79d0b3f0f4/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.18' not found (required by /target/debug/build/backtrace-4d922e79d0b3f0f4/build-script-build)

On archlinux x86_64
Rust has been installed through rustup

on running
cross build
I have:
[1] 31972 segmentation fault (core dumped) /home/rog/.cargo/bin/cross build

Reproduced on two machines with archlinux x86_64 installed on it

I've been trying to debug our CI failures by running cross locally, but I've run into Permission denied error when doing so. I'm not really certain where to look to try and debug this issue, so I'm posting here. Any help figuring this out would be appreciated.

$ cross build --target aarch64-unknown-linux-gnu
Unable to find image 'japaric/aarch64-unknown-linux-gnu:v0.1.10' locally
Trying to pull repository docker.io/japaric/aarch64-unknown-linux-gnu ... 
sha256:7bd5365e6aec2cdcab009e59039117f3e8b5e25b089d28d30036a10739225fdc: Pulling from docker.io/japaric/aarch64-unknown-linux-gnu
30d541b48fc0: Pull complete 
8ecd7f80d390: Pull complete 
46ec9927bb81: Pull complete 
2e67a4d67b44: Pull complete 
7d9dd9155488: Pull complete 
08aa1b431028: Pull complete 
7d802a03e2fb: Pull complete 
a37098550b32: Pull complete 
031c3405b7a7: Pull complete 
Digest: sha256:7bd5365e6aec2cdcab009e59039117f3e8b5e25b089d28d30036a10739225fdc
Status: Downloaded newer image for docker.io/japaric/aarch64-unknown-linux-gnu:v0.1.10
sh: 1: cargo: Permission denied

The Python Wheel format requires Linux wheels containing compiled binaries to be built using particular versions of glibc, libstdc++ etc, on a CentOS 5.11 distro, specified in PEP 513 to ensure wide compatibility. x86_64 and i686 Docker images to do this are available and maintained by the community, and installing rustup and building libs works fine, but it's an extra step, requiring modifications to a trust setup in order to pull the docker image, install rustup, copy the binaries etc.
Would it be possible for cross to provide these images as targets? I'm happy to work on the PR if you're open to it.

Being able to run the docker command is equivalent to being root, which is why I'm not quite comfortable adding my regular user to the docker group.

Running docker via sudo is fine, but cross doesn't do this, so I'd have to run cross itself via sudo, which in turn causes all sorts of problems: Build files would be created that belong to root, rustup uses root's configuration (which doesn't exist in my case), and it's just running much more code than necessary as root (including random build scripts of any dependencies, I think!).

This tells me that being in the docker group is indeed the preferred way of using cross (right?), which is already a bit questionable, but there's also no way to get around this, so I'd like some way of configuring how docker is invoked.

rust-lang/cargo#3553

Cross is lacking support for custom docker images. Custom images should be used either by default or optionally.

Option 1:

Cross looks on launch for an image called <target>:<tag> where <tag> is optionally specified with a flag --tag (if none then default tag, i.e latest or latest tagged version). If successful, cross will later launch docker with the specified image. If unsucessful, cross will load japaric/<target>:<tag> (<tag> is also the default here). Cross will also take a docker-image flag to fully specify what image to be used, i.e using other-user/foo:<tag> or <local-image>:<tag> where the user simply gives the full path to cross.

Option 2:

Cross does the same as Option 1 but doesn't look for another image but japaric/<target>:<tag>unless any is specified.

Things to consider

• cargo --tag is currently undefined, however it could be used in the feature, using --docker-tag could be safer to use for future compatability reasons.
• Instead of just using flags for cross --docker-image myimage, also consider using enviromental variables for this, possible even using dotenv.
• When user specifies a full path to an image, parse it with docker_image.replace("{target}", target) so that when using cross --target=<target> --docker-image={target}:v0.1.0, the docker-image will be expanded and set to <target>:v0.1.0.

Everything is funneled through stdout

I get this error in Travis:

error: failed to run `rustc` to learn about target-specific information

Complete job is here: https://travis-ci.org/nix-rust/nix/jobs/223220714

I have integration tests which run a binary. Normally, they invoke "target/debug/foo". However, when testing under cross, the binaries are in "target/TARGET/debug/foo".

Would it be possible to export the TARGET variable so that they can be accessed in tests and used to locate built binaries?

I would use "cargo run" but I need to change the cwd of the process to one not under the crate root, so that won't work.

It looks like the v0.1.11 tag wasn't deployed for the x86_64-unknown-linux-gnu target. This has broken testing for us.

When I try to visit https://www.kernel.org/doc/Documentation/binfmt_misc.txt , I get 404 http status.

(This is a feature request)

Since OpenSSL is available in the Docker images, I think it would make sense for there to be a C++ environment as well; arguably it's more common to depend on a C++ library that needs to be cross-compiled than depending on OpenSSL (maybe OpenSSL is more common when dealing with network-related libraries?).

There would need to be a compiler available for the target platform; there would preferably also be an ENV layer in the Docker image that sets environment variables that are compatible with https://github.com/alexcrichton/gcc-rs (e.g. HOST_CXX, TARGET_CXX)

Of course libstdc++ would also be cross-compiled and match the chosen compiler.

https://github.com/nix-rust/nix has been using cross for its CI tests for a few months now. But on about 25-June, all of our Travis builds started to fail with the error message:

error: "rustup" "target" "list" failed with exit code: Some(1)

I don't know why it started on 25-June. It's probably either a change to Travis (they updated their builders, but they claim it was done by 21-June), or Rustup, or Cross. It looks like cross is refusing to run without a default target, even though cross itself should be installing the toolchain. Do you have any idea why? At the very least, it should print rustup's full error message.

https://travis-ci.org/nix-rust/nix/builds/246718360

Downstream bug: nix-rust/nix#634

Right now, something like this produces an error:

$ cargo add foo
$ cross build
error: failed to write /project/Cargo.lock

Caused by:
  failed to open: /project/Cargo.lock

I have my dockerd configured to run under an unprivileged user. However, it seems this is not really supported by cross:

$ cross test --target armv7-unknown-linux-musleabihf
docker: Error response from daemon: Privileged mode is incompatible with user namespaces.
See 'docker run --help'.
error: `"docker" "run" "--privileged" "--rm" "-it" "ubuntu:16.04" "sh" "-c" "apt-get update && apt-get install --no-install-recommends -y binfmt-support qemu-user-static"` failed with exit code: Some(125)
note: run with `RUST_BACKTRACE=1` for a backtrace

It fails with a different error with build, which probably could be solved by granting some unreasonable permissive permissions to ~/.cargo:

docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:359: container init caused \"rootfs_linux.go:54: mounting \\\"/home/vorner/.cargo\\\" to rootfs \\\"/var/lib/docker/231072.231072/btrfs/subvolumes/9a8dd48eec320f381e259e8640fb3414aa0baa4874c540c1334396d7a739bffc\\\" at \\\"/cargo\\\" caused \\\"stat /home/vorner/.cargo: permission denied\\\"\"".

Would it be viable to support these more paranoid modes of operation, or at least document this is not supported and why?

@japaric would you be open to a refactor of Target break things up a bit. I'm thinking something like what appears in the LLVM source. This would allow is_bsd() to be reduced to:

fn is_bsd(&self) -> bool {
    match self.os {
        FreeBsd | NetBsd | Dragonfly | OpenBsd => true,
        _ => false
    }

and other similar simplifications. The outline I'm imagining is this:

pub struct Triple {
    arch: Arch,
    sub_arch: Option<SubArch>,
    vendor: Vendor,
    os: Os,
    environment: Environment,
}

pub enum Arch {
    X86,
    X86_64,
    /* ... */
}

// Mosty for ARM.
pub enum SubArch {
    ArmV7,
    /* ... */  // Not actually that many for the purposes of cross
}

pub enum Vendor {
    Unknown,
    Apple,
    Pc,
    /* ... */
}

pub enum Os {
    Linux,
    Darwin,
    Windows,
    /* ... */
}

pub enum Environment {
    Gnu,
    GnuEabi,
    GnuEabiHf,
    Musl,
    /* ... */
}

x86_64-unknown-dragonfly, armv7-unknown-linux-musleabihf, and arm-unknown-linux-musleabihf are affected. I think this is because rustup doesn't have support for installation on those platforms (see here).

https://travis-ci.org/mgattozzi/alchemist/jobs/205057554#L632

We have to install diesel_cli as part of install in order to run database migrations. However because of this when building the project, it errors because diesel is already installed.

Trying to get this to work correctly and one thing I want to do is use the thumbv7em-none-eabi target. I want to use 6.2.0/ but cross provides 4.9.3. How do I change this (if possible)

How could a cross user automatically build for every supported target, like gox?

Is there a command invocation that lists the supported triples?