Open timwalls opened 3 years ago
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.
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: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:
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.