Broken image for linux/arm/v7
Hi all,
I discovered a bit of a problem with the linux/arm/v7 version of the Rust image - attempting to build Rust projects with it breaks in various mysterious ways with errors like this:
> [builder 6/12] RUN cargo install cargo-build-dependencies:
#14 0.834 Updating crates.io index
#14 1.590 warning: spurious network error (2 tries remaining): could not read directory '/usr/local/cargo/registry/index/github.com-1285ae84e5963aae/.git//refs': Value too large for defined data type; class=Os (2)
#14 2.087 warning: spurious network error (1 tries remaining): could not read directory '/usr/local/cargo/registry/index/github.com-1285ae84e5963aae/.git//refs': Value too large for defined data type; class=Os (2)
#14 2.628 error: failed to fetch `https://github.com/rust-lang/crates.io-index`
#14 2.628
#14 2.628 Caused by:
#14 2.629 could not read directory '/usr/local/cargo/registry/index/github.com-1285ae84e5963aae/.git//refs': Value too large for defined data type; class=Os (2)
------
failed to solve: rpc error: code = Unknown desc = executor failed running [/bin/sh -c cargo install cargo-build-dependencies]: exit code: 101
I can't say for certain the cause, but I can say that if you install Rust on linux/arm/v7 using the "standard" sh.rustup.rs script, it is also broken, because of this function:
get_bitness() {
need_cmd head
# Architecture detection without dependencies beyond coreutils.
# ELF files start out "\x7fELF", and the following byte is
# 0x01 for 32-bit and
# 0x02 for 64-bit.
# The printf builtin on some shells like dash only supports octal
# escape sequences, so we use those.
local _current_exe_head
_current_exe_head=$(head -c 5 /proc/self/exe )
if [ "$_current_exe_head" = "$(printf '\177ELF\001')" ]; then
echo 32
elif [ "$_current_exe_head" = "$(printf '\177ELF\002')" ]; then
echo 64
else
err "unknown platform bitness"
fi
}
This fails to set the bitness to 32bit, instead falling through to "unknown platform bitness" (because no /proc/self/exe), resulting in a broken installation of Rust.
If the Docker image build uses that standard rustup script, that's probably why the image is also broken.
It does not use the rustup script: https://github.com/rust-lang/docker-rust/blob/master/1.50.0/buster/Dockerfile#L17
That's a shame, 'cos it's obviously broken for some other reason then.
I don't have any ARM hardware to test with unfortunately, but it seems like this could be a problem with how libgit2 is compiled for Armv7 in Cargo's dists: https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Value-too-large-for-defined-data-type. You may want to file an issue over there.
Hmm. Interesting. Everything works fine if I build myself in a container using the rustup script and a patch to that get_bitness() function, so I'm somewhat surprised if the problem lies in any other libraries, but it's possible I guess.
I don't really have time to debug right now, but if I get a chance I'll try to dig into the Rust image a bit to find the problem.
Definitely worth checking which specific rustup binary the script ended up downloading. If it was something other than the armv7-unknown-linux-gnueabihf version then that would explain the difference, though I don't know enough about the ARM ecosystem to know where to go from there.