Closed darayus closed 8 years ago
Thanks for looking into this. Could you please try the ARMv6-armhf nightly? Those are built on a Raspbian wheezy container with glibc 2.13-38.
I haven't started producing stable or beta builds for them yet as I am unsure if the build system is configured correctly to account for the older glibc.
Once I've confirmed that the raspbian container is building glibc 2.13 compatible builds, I'll entertain the idea of moving my default ARMv7 container over to a Wheezy image with simiar customizations to the Raspbian container for ARMv7 builds with glibc 2.13.
I've just pulled my Raspberry Pi B from storage, I'll start work on getting an up to date raspbian installed on it and testing there. We'll see what happens. It looks like I might've missed some setup in the raspbian environment, so the ARMv6 binaries might not be properly linked with glibc 2.13 like I previously though.
EDIT: Confirmed not working on the Raspbery Pi B I have. Started working on fixing this for the ARMv6-armhf binaries first.
I have managed to get it to work on Ubuntu Mate for the Raspberry Pi 2 as it uses a newer glibc. I assume the glibc dependency is backwards compatible so that a build targeted at an old glibc will still run with a newer glibc.
I also have a Raspberry Pi B available so please let me know if you need me to test anything out.
Correct, the glibc dependency is backwards compatible. The ARMv7 builds are currently built in a Debian jessie container with glibc at version 2.19. I'm currently working on rebuilding my Raspbian container to be complient with the requirements of building rust and cargo while still staying on glibc 2.13.
I've successfully compiled a rust snapshot compiler in the Raspbian container, and am in the middle of building a full rust compiler. If this change works, I'll do a build of Cargo and let the automated build process take over building ARMv6 binaries. Since tomorrow would be the first full run of the ARMv6 binaries, it'll take 9-12 hours to compile the required snashots and compilers for nightly, beta and stable.
I haven't made a decision on how I want to move the ARMv7 builds back as I want to still compile with Clang as it is faster overall. (Clang in the Raspbian container is too old to compile rust at all.)
In the meantime, if this setup works, could you try the new ARMv6-armhf binaries on your Raspberry Pi 2 (Both Ubuntu Mate and Raspbian)? ARMv6 binaries, while not optimized for ARMv7 hardware should still work. It seems like @japaric used a raspbian container for all his builds, so my ARMv6 builds are the equivalent of his. I have a Raspberry Pi B that I will test it on as well.
Thanks!
EDIT: The latest build of the ARMv6-armhf container works on my Raspberry Pi B! Just have to see if Cargo will build, that might be trickier.
I have just tested the new ARMv6 build on my Raspberry Pi B and it works! I am currently updating my Raspberry Pi 2 to Debian Jessie so i'll test it there as well once the upgrade is complete. Below are the outputs for the current rustc
.
Rust Version:
pi@raspberrypi ~/RustTest $ rustc -V
rustc 1.4.0-dev (205c356ac 2015-09-05)
A sample hello world program:
pi@raspberrypi ~/RustTest $ rustc helloworld.rs
pi@raspberrypi ~/RustTest $ ./helloworld
Hello World
The latest cargo nightly builds and runs
pi@raspberrypi ~ $ cargo -V
cargo 0.5.0-nightly (ec59a6c 2015-09-04)
pi@raspberrypi ~ $ rustc -V
rustc 1.4.0-dev (205c356ac 2015-09-05)
However it doesn't actually build anything... :(
pi@raspberrypi ~/dev/sothr_lib $ cargo build
Illegal instruction
I'm looking into it now, my guess is I somehow have some leaking ARMv7 opcode working it's way in. Possibly in the static openssl library, I'm going to try downgrading that first.
So, I think I was right. I'm building a version of the openssl library from the source because of fPIC errors with the Debian development ones. Even with the -march=armv6 flag it wasn't building an armv6 version. Got it working in the end though by falling back on the full configuration script for the openssl library.
pi@raspberrypi ~/dev/sothr_lib $ rustc -V
rustc 1.4.0-dev (205c356ac 2015-09-05)
pi@raspberrypi ~/dev/sothr_lib $ cargo -V
cargo 0.5.0-nightly (ec59a6c 2015-09-04)
pi@raspberrypi ~/dev/sothr_lib $ cargo build --release
Updating registry `https://github.com/rust-lang/crates.io-index`
Downloading winapi-build v0.1.1
Downloading num v0.1.27
Downloading rustc-serialize v0.3.16
Downloading rand v0.3.11
Downloading advapi32-sys v0.1.2
Downloading winapi v0.2.2
Downloading libc v0.1.10
Compiling libc v0.1.10
Compiling rustc-serialize v0.3.16
Compiling winapi-build v0.1.1
Compiling winapi v0.2.2
Compiling advapi32-sys v0.1.2
Compiling rand v0.3.11
Compiling num v0.1.27
Compiling sothr_lib v0.0.1 (file:///home/pi/dev/sothr_lib)
src/str_util.rs:9:5: 9:29 warning: use of deprecated item: use the equivalent methods on `Iterator` instead, #[warn(deprecated)] on by default
src/str_util.rs:9 use std::iter::order::equals;
^~~~~~~~~~~~~~~~~~~~~~~~
src/str_util.rs:58:3: 58:9 warning: use of deprecated item: use the equivalent methods on `Iterator` instead, #[warn(deprecated)] on by default
src/str_util.rs:58 equals(iter.take(n), iter_rev.take(n))
^~~~~~
This look good, so I'm going to let the auto build take over for the night and look/work though any of the bugs in the morning!
Also... The Raspberry Pi B is sooooo slow at compiling.
The auto build just completed all of the binaries, which are now out in the ARMv6-armhf directory. Here's the output of each on my Raspberry Pi B, running Raspbian Wheezy. 1.2.0 Stable
pi@raspberrypi ~/dev/sothr_lib $ multirust run unofficial_stable rustc -V
rustc 1.2.0 (082e47636 2015-08-03)
pi@raspberrypi ~/dev/sothr_lib $ multirust run unofficial_stable cargo -V
cargo 0.5.0-nightly (ec59a6c 2015-09-04)
pi@raspberrypi ~/dev/hello_world $ multirust run unofficial_stable cargo build
Compiling hello_world v0.1.0 (file:///home/pi/dev/hello_world)
pi@raspberrypi ~/dev/hello_world $ multirust run unofficial_stable cargo run
Running `target/debug/hello_world`
Hello, world!
1.3.0 Beta
pi@raspberrypi ~/dev/hello_world $ multirust run unofficial_beta rustc -V
rustc 1.3.0-beta.3 (2a89bb6ba 2015-08-11)
pi@raspberrypi ~/dev/hello_world $ multirust run unofficial_beta cargo -V
cargo 0.5.0-nightly (ec59a6c 2015-09-04)
pi@raspberrypi ~/dev/hello_world $ multirust run unofficial_beta cargo build
Compiling hello_world v0.1.0 (file:///home/pi/dev/hello_world)
pi@raspberrypi ~/dev/hello_world $ multirust run unofficial_beta cargo run
Running `target/debug/hello_world`
Hello, world!
1.4.0 Nightly
pi@raspberrypi ~/dev/hello_world $ multirust run unofficial_nightly rustc -V
rustc 1.4.0-dev (205c356ac 2015-09-05)
pi@raspberrypi ~/dev/hello_world $ multirust run unofficial_nightly cargo -V
cargo 0.5.0-nightly (ec59a6c 2015-09-04)
pi@raspberrypi ~/dev/hello_world $ multirust run unofficial_nightly cargo build
Compiling hello_world v0.1.0 (file:///home/pi/dev/hello_world)
pi@raspberrypi ~/dev/hello_world $ multirust run unofficial_nightly cargo run
Running `target/debug/hello_world`
Hello, world!
These look good, so I'm going to close the issue. Feel free to re-open it if you find another bug in these binaries.
I have downloaded the stable rust 1.2 binaries but the glibc version required is higher than the version provided by the Raspbian sources. This is a similar issue to https://github.com/japaric/ruststrap/issues/18. I am using the ARMv7 binaries as I am on a Raspberry Pi 2.
The default glibc version on Raspian is 2.13:
When running
rustc
, the following error is produced:Please let me know if there is any more information that you need and thanks for taking over from @japaric :thumbsup:!