Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Consider using different Docker tags for ARM and x86_64 platforms #63

Closed
frol opened this issue Nov 30, 2018 · 5 comments
Closed

Consider using different Docker tags for ARM and x86_64 platforms #63

frol opened this issue Nov 30, 2018 · 5 comments

Comments

@frol
Copy link
Contributor

frol commented Nov 30, 2018

I have just noticed that the Dockerfile pulls Rust and GCC toolchains for ARM platform along with x86_64. There are a few points why I find it cumbersome:

  • The image size is noticeably affected.
  • The popular libraries are only built for x86_64, thus the ARM target is not on par with x86_64.
@emk
Copy link
Owner

emk commented Nov 30, 2018

Yeah, this is a bit of an open question still. The ARM code was submitted by a very kind user, and I have an actual use case for it myself. But we don't yet have a generalized mechanism to support all C libraries on both platforms yet—possibly because there's much less demand for most of those C libraries on ARM.

This will probably get redesigned at some point to be cleaner. But it's not at the top of my priority list.

@KEINOS
Copy link

KEINOS commented Feb 6, 2019

I understand the priority and would like to respect that. Thanks for the effort of maintening it.
On the other hand, I would like to +1 for this consideration.

On Mac:

$ docker pull ekidd/rust-musl-builder:stable
$ docker run --rm -it ekidd/rust-musl-builder:stable /bin/bash
rust@526deb2c064b:~/src$ 

The container boots straight with no problem. Then I was able to multi-stage-build the RipGrep to make it work on Alipine. And it worked like a charm.

Thanks for rust-musl-builder and the documentation. With this container, even for the rust begginer like I, it was amazingly easy to build the rust env and it's bin.

standard_init_linux.go:190: exec user process caused "exec format error" on RPi

Though on RPi3 Jessie:

$ docker pull ekidd/rust-musl-builder:stable
$ docker run --rm -it ekidd/rust-musl-builder:stable /bin/bash
standard_init_linux.go:190: exec user process caused "exec format error"

😭 I got the above error and drifted to this issue. I think this error comes from the same reason with this isse.

Env info
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
$ uname -a
Linux RaspberryPi 4.14.41-v7+ #1113 SMP Thu May 17 16:29:48 BST 2018 armv7l GNU/Linux

@humb1t
Copy link

humb1t commented Oct 14, 2019

standard_init_linux.go:211: exec user process caused "exec format error"

The same thing with nightly on RPI4

@emk
Copy link
Owner

emk commented Jan 26, 2020

Ouch. I'm really sorry to hear about this, and I'd be happy to review a PR improving the ARM situation. ARM is a great architecture with lots of uses, and I'd love to have support for it. And I really appreciate the effort that everybody has put into bug reports.

But I don't see much chance of me getting to this in a reasonable amount of time. :-( My apologies.

emk added a commit that referenced this issue Sep 6, 2020
This PR attempts to lay the groundwork to address
#96. In particular, we
install the Rust toolchain globally by abusing `rustup`.

We still preserve the legacy `rust` user but we now encourage derived
Dockerfiles to consider `USER root`.

This PR also removes ARM support. We want to explore the idea of
supporting ARM more reliably using a separate image, but perhaps it
would be better to refer those users to one of the Rust
cross-compilation toolchains. See
#63 for discussion.
@emk
Copy link
Owner

emk commented Jan 5, 2021

Due to a number of problems with the ARM support, including the fact that it provided very few libraries compared to the Intel toolchain—and the fact that I have neither the time nor an ARM system to maintain it properly—I've gone ahead and dropped ARM support.

I would consider adding it back if someone has a plan for (1) release it under a different tag, (2) supporting the same C libraries as the Intel version (more or less), and (3) automatically testing it for each release.

@emk emk closed this as completed Jan 5, 2021
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

4 participants