Please include an ARM targeted version of rustc.

I'm trying to actually use rustc ON a raspberry pi. On an x64 machine, I tried compiling a cross-compiling rustc targetting ARM and then using that to cross-compile rust itself for ARM:

$ apt-get install g++-arm-linux-gnueabihf
$ git clone https://github.com/mozilla/rust.git
$ mkdir rust/build-cross
$ cd rust/build-cross
$ ../configure --target=arm-unknown-linux-gnueabihf --prefix=$HOME/local/rust-cross
$ make -j8 && make install
$ cd ..
$ mkdir build-arm
$ cd build-arm
$ ../configure --enable-local-rust --local-rust-root=/home/local/rust-cross --target=arm-unknown-linux-gnueabihf
$ make

But that finally fails with:

rustbuild@rustbuild-VirtualBox:~/repos/rust/rust-arm$ make
...lots and lots of compilations looking successful...
cfg: version 1.5.0-dev (04e497c00 2015-10-24)
cfg: build triple x86_64-unknown-linux-gnu
cfg: host triples x86_64-unknown-linux-gnu
cfg: target triples x86_64-unknown-linux-gnu arm-unknown-linux-gnueabihf
cfg: non-build target triples arm-unknown-linux-gnueabihf
cfg: host for x86_64-unknown-linux-gnu is x86_64
cfg: host for arm-unknown-linux-gnueabihf is arm
cfg: os for x86_64-unknown-linux-gnu is unknown-linux-gnu
cfg: os for arm-unknown-linux-gnueabihf is unknown-linux-gnueabihf
cfg: good valgrind for x86_64-unknown-linux-gnu is 1
cfg: good valgrind for arm-unknown-linux-gnueabihf is 
cfg: using CC=gcc (CFG_CC)
cfg: disabling valgrind run-pass tests
rustc: x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore
../src/libcore/lib.rs:1:1: 1:1 error: can't find crate for `std`
../src/libcore/lib.rs:1 // Copyright 2014 The Rust Project Developers. See the COPYRIGHT
                        ^
error: aborting due to previous error
make: *** [x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/stamp.core] Error 101

error: can't find crate for std

that error is a result of using these: --enable-local-rust --local-rust-root=/home/local/rust-cross

I don't think using local rust is working properly (I've only tried it for host x86_64-unknown-linux-gnu, not arm)

If someone knows how to fix it, please share...

I tried adding --enable-rpath to the first ./configure ... because I was even getting the following without it:

rustbuild@rustbuild-VirtualBox:~/local/rust-cross/bin$ ./rustc --version
./rustc: error while loading shared libraries: librustc_driver-bb943c5a.so: cannot open shared object file: No such file or directory

So I remade/reinstalled to rust-cross and now the rust-cross/bin/rustc --version gives rustc 1.5.0-dev (04e497c00 2015-10-24) and unexpectedly the output of ./rustc helloworld.rs runs correctly locally. Is it possible that these two outputs are compatible for both processors because it is such a simple program (467kb still!!)? I wouldn't expect it to run so otherwise I assume that it's not targeting the right processor.

[alexcrichton]

Yes unfortunately it's a known problem right now that you can't bootstrap the compiler for a target which you can't yourself run locally (e.g. nothing other than i686 -> x86_64 or vice versa works).

We've actually just recently started to produce artifacts for the standard library (you can see more as well) and the tooling will soon be updated to help you install those locally! It means you'll have to have a cross compiler available (and won't be able to run rustc itself on the device), but it should at least get some of the way there.

As this is tracked elsewhere, though, I'm going to close for now.

Can you please elaborate on whether we'll be able to compile rust ON an arm processor? Or why not? I'm having trouble sifting through all the information. If I could get this compiler on an arm tablet, I think that'd be the only non-phone computer I'd need anymore!

[alexcrichton]

There have been efforts to get an arm host compiler (a rustc which runs on an arm processor), but they haven't been moved into our build system as of yet. The build system currently attempts to bootstrap any host target (those which have compilers built) from themselves, but this doesn't work if you're crossing from x86 -> arm because you can't actually run the arm compiler, and this is tracked by #5258.

We'd certainly like this to be a possibility, however! I know of no fundamental blocker preventing the compiler from running on an arm processor, it's just a limitation of our build system.