cross-rs / cross Goto Github PK
View Code? Open in Web Editor NEW“Zero setup” cross compilation and “cross testing” of Rust crates
License: Apache License 2.0
“Zero setup” cross compilation and “cross testing” of Rust crates
License: Apache License 2.0
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
--privileged
flagThe 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
.
@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.
Everything is funneled through stdout
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
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!
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.
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
(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.
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
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.
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.
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
How could a cross
user automatically build for every supported target, like gox?
Is there a command invocation that lists the supported triples?
Cross is lacking support for custom docker images. Custom images should be used either by default or optionally.
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.
Cross does the same as Option 1 but doesn't look for another image but japaric/<target>:<tag>
unless any is specified.
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.cross --docker-image myimage
, also consider using enviromental variables for this, possible even using dotenv.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
.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
When I try to visit https://www.kernel.org/doc/Documentation/binfmt_misc.txt , I get 404 http status.
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.
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.
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)
@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,
/* ... */
}
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.
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.
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?
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)
It seems that Cargo is not passing -C linker=foo to rustc for that particular subcommand.
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
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.
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'd be very interested in an OpenBSD target :)
Currently you have to run the command with RUST_BACKTRACE=1
. This could possibly be a set flag/config setting for cross for debug.
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.
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.
this would save us a docker call
the downside is that this requires sudo
/ root privilege
Supporting cross compilation from unix to *-pc-windows-gnu is easy with the mingw toolchain, which happens to include .lib
s for the system libraries.
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
We can get a little further by setting QEMU_CPU=something
in the environment but then instead QEMU segfaults instead of throwing an error.
$ echo hello | cross run
the input device is not a TTY
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.
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.
Will this help me compile a rust binary on my Mac that I want to distribute and run on an Ubuntu server?
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
if there isn't one at the root of the Cargo project.
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).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.