`rustup-init.sh` fails to detect platform correctly under `docker buildx` which lacks `/proc`

[miigotu]

rustup-init.sh installs the incorrect rustc and other binaries because of a failure to detect arch.
Problems: /proc/self/exe does not exist during docker build, so i686/386 etc is detected incorrectly as x86_64 due to failure on line 153. mips64 likely suffers the same issue because it also uses get_bitness

grep '^Features' /proc/cpuinfo | grep -q -v neon fails and ARMv6 is incorrectly detected as arm7 on line 367
Running the downloaded binary fails with /lib/ld-linux-armhf.so.3: No such file or directory (because it isnt armhf, it is armel at /lib/ld-linux.so.3 )

Logs and example code to produce the container and error:
https://gist.github.com/miigotu/2a0b80677420d806c96d8e792ae6652e

Note: gcc inside the container reports the correct info, kernel reports x86_64

root@386c88edfbc5:/# uname -m
x86_64
root@386c88edfbc5:/# gcc -dumpmachine | sed "s/-/-$(uname -p)-/"
i686-unknown-linux-gnu

and

root@dac44b74e4c0:/# uname -m
armv7l
root@dac44b74e4c0:/# gcc -dumpmachine | sed "s/-/-$(uname -p)-/"
arm-unknown-linux-gnueabi

[kinnison]

We use /proc/self/exe because that tends to tell us the userland host type rather than uname -m which would tell us the kernel architecture. Yes it's possible that's correct, but it's also possible for it to be wrong. E.g. some aarch64 systems can run 32-bit userlands, some armhf kernels can run armel userlands, etc.

It sounds like this is a limitation of docker buildx somehow not providing /proc which is unfortunate.

Any work to correct this would need to be fallback code in rustup-init.sh where if it cannot use /proc/self for some reason it looks at alternatives with suitable warnings.

If someone wants to work on this, please talk to us on the Rust discord in #wg-rustup because it will need some careful discussion.

[miigotu]

This is my temporary solution that works (building python cryptography):

# rust installer needs patched to get the correct binaries for ARMv6 and i686
RUN sed -i -e's/ main/ main contrib non-free/gm' /etc/apt/sources.list
RUN apt-get update -q && \
 apt-get install -yq build-essential curl git libssl-dev libffi-dev libxml2 libxml2-dev libxslt1.1 libxslt-dev libz-dev mediainfo python3-dev unrar nano && \
 pip install -U pip wheel && \
 curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs > rustup-init.sh && \
 sed -i 's#/proc/self/exe#$(which head)#g' rustup-init.sh && \
 sed -i 's#/proc/cpuinfo#/proc/cpuinfo 2> /dev/null || echo ''#g' rustup-init.sh && \
 sed -i 's#get_architecture || return 1#RETVAL=$(gcc -dumpmachine | sed "s/-/-unknown-/") #g' rustup-init.sh && \
 sh -x rustup-init.sh -y --default-host=$(gcc -dumpmachine | sed 's/-/-unknown-/') && \
 rm rustup-init.sh && \
 PATH=$PATH:$HOME/.cargo/bin pip install --no-cache-dir --no-input -Ur requirements.txt && \
 PATH=$PATH:$HOME/.cargo/bin rustup self uninstall -y && \
 apt-get purge -yq --autoremove build-essential libssl-dev libffi-dev libxml2-dev libxslt-dev libz-dev python3-dev && \
 apt-get clean -yq && rm -rf /var/lib/apt/lists/*

[workingjubilee]

I do not believe all BSDs support /proc, so I am labeling this as a BSD issue until it is confirmed otherwise.
@rustbot label:+O-bsd

[miigotu]

I do not believe all BSDs support /proc, so I am labeling this as a BSD issue until it is confirmed otherwise.
@rustbot label:+O-bsd

This is debian buster

[workingjubilee]

True, but the relevant high-order bit there seemed to be
@rustbot label: +O-containers