You should now be able to use rustup or multirust to install the nightly version of rustc and
cargo on these hosts:
arm-unknown-linux-gnueabi: 32-bit ARMv6/ARMv7 without FPU
arm-unknown-linux-gnueabihf: 32-bit ARMv6/ARMv7 with FPU
armv7-unknown-linux-gnueabihf: 32-bit ARMv7 with FPU
aarch64-unknown-linux-gnu: 64-bit ARMv8
x86_64-unknown-freebsd
x86_64-unknown-netbsd
Some comments:
I have only tested the arm-gnueabihf and armv7-gnueabihf triples. Do let us know if you have any
problem using these binary releases or with rustup/multirust on these platforms by opening an issue
in the respective repository.
rustup installs the arm-unknown-linux-gnueabihf toolchain instead of the armv7 one on ARMv7
devices because of a limitation in the auto-detection mechanism. You can install the armv7 toolchain
using the command rustup default nightly-armv7-unknown-linux-gnueabihf. And you definitely want
the armv7 toolchain because is faster (cargo building hyper takes half the time) than the arm
toolchain. multirust doesn't have this problem.
Bonus: OpenWRT
You can also use multirust/rustup to install cross compiled std crates for these targets:
mips-unknown-linux-musl
mipsel-unknown-linux-musl
These std crates plus the OpenWRT SDK can be used to cross compile Rust apps for OpenWRT
(trunk edition) devices. For an example of how to do this check the Travis CIconfiguration of
the rust-cross repository.
Final note
All these targets are tier 2/3 platforms so either (a) we don't run the full test suite on
these targets (like ARM Linux) or (b) we run the test suite but don't block PRs on the success of
running the test suite on these targets (like FreeBSD). This means that you may find bugs than we
are not aware of; if you do please report them on the rust-lang/rust issue tracker!
Oh, and if you want to thank someone. Thank @alexcrichton, he has done all the hard work here.
in case of my raspberry pi, it completely avoided cross compiling all together.
I agree with this. If you can avoid cross compiling, you are better off with building natively on the target platform. It will save you some headaches. (see below)
Is this going to lead very soon to even easier cross-compiling perhaps?
rustup/multirust have made cross compiling easier from a logistics point of view, you can use them to easily install the cross compiled standard crates.
The difficult part of cross compiling that remains is C. In theory we could help here by providing some tool that installs a C cross compiler and a cross compiled libc. That would help with projects that use pure Rust. But, as soon as your project needs to bind a C library all sort of problems arise: you link your cross compiled Rust app to the system/host C library instead of the cross compiled C library, or the cross compiled C library in the host is not ABI compatible with the C library on the target, etc. For some targets (Android and OpenWRT) we can address these problems by installing an SDK which is a bunch of cross compiled C libraries guaranteed to be ABI compatible with the target platform where the binary is going to be deployed. For other targets, I don't know of a general solution to eliminate these problems for the users. (Other than teaching the users how to fix these problems on their own)
More musl? Will i686-unknown-linux-musl also arrive, so one can deploy Rust apps onto legacy servers?
Yes! I landed some of the stuff required required to build std for that target but I think the related infrastructure hasn't been "turned on" yet. cc @alexcrichton
rustup is going to grow "ndk" support, which just means that we'll slowly teach it how to install the needed native components for common host->target combinations. We'll start with easy stuff like automatically installing and configuring the Android SDK/NDK to work with Rust. Then maybe linux-gnu->linux-musl, etc.
Still haven't thought through the details and it'll probably be another month before I start on it.
When I try to install rustup with curl https://sh.rustup.rs -sSf | sh on my FreeBSD machine, I get the error thread '<main>' panicked at 'not yet implemented', src/multirust-dist/src/dist.rs:390.
Is there a different way I'm supposed to be installing it? The "about" page for rustup hasn't been updated to list FreeBSD in the list of supported architectures, so I'm not sure what else to try.
Thanks for the report. I have opened an issueand I'll look into it. I think we have already solve the problem and the next rustup release should work. I'll ping you when the new release is ready.
EDIT: On trying to install multirust, I get the same error. This actually isn't too surprising to me, given that the error is shown as coming from multirust code.
EDIT: On trying to install multirust, I get the same error. This actually isn't too surprising to me, given that the error is shown as coming from multirust code.
That sounds weird multirust is written in Bash, rustup is written in Rust.
Did you uninstall rustup (rustup self uninstall) first? It seems you executed the multirust that rustup.rs installed which is the same as the rustup binary. file $(which multirust) should return a /usr/bin/env bash script, ASCII text executable.
Oh, right. Not sure how I managed to forget to do that...
Thanks so much! This is really helpful for FreeBSD, since the only way I had heard of to get the FreeBSD cargo package working with the rust-nightly one was to compile the cargo port from source, which was not fun...
rustup 0.1.6 is out with some fixes from @japaric for host plattform detection. This should make the arm7 build target arm7 by default and make the FreeBSD build not panic.
I have a couple of machines and boards running FreeBSD amd64 and Arch Linux 32-bit ARMv7 + FPU, so I will definitely try them out!
Well, on FreeBSD amd64, multirust is failing when I try to install the stable one.
/home/tatsuya% multirust update stable
multirust: installing toolchain 'stable'
rustup: gpg available. signatures will be verified
rustup: downloading manifest for 'stable'
gpg: Warning: using insecure memory!
rustup: assert_nz url is empty!
I am using multirust installed only a couple of hours ago.
/home/tatsuya% multirust --version --verbose
multirust: checking metadata version
multirust: got metadata version 2
multirust 0.8.0 (0d98a59f7 2016-04-14 19:44:05 -0700)
/home/tatsuya% freebsd-version
10.3-RELEASE
/home/tatsuya% uname -a
FreeBSD minibsd.home.lan 10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25 02:10:02 UTC 2016 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
I had no problem installing beta and nightly on this machine, so I have a feeling that it just cannot find the manifest for stable. Is there any way to debug? --verbose option does not work with multirust default and update commands.
It is not urgent though. I set beta as my default tool chain because I want to use std::panic::catch_unwind() for my project using FFI.
multirust default stable won't work because there are no stable releases for these hosts (hence they don't appear in the manifest). There were some changes needed in the rust and cargo repos to get these hosts working that barely made it into this last beta. IOW, Rust 1.9 (6 weeks from now) will be the first stable release to provide binary releases of rustc and cargo for these hosts.
xmas in april right now 