Rust musl Docker изображение не может найти груз

Question

Я пытаюсь запустить Rust в Docker, чтобы использовать его для 32-битных сборок musl.С тех пор, как я обновил его, чтобы использовать новый URL для извлечения ржавчины, я сталкиваюсь с этой проблемой при интерактивном запуске контейнера с помощью bash:

root@2c3549fe3169:/sample# cargo
error: command failed: 'cargo'
info: caused by: No such file or directory (os error 2)

Странно то, что я вижу исполняемые файлы

root@2c3549fe3169:/sample# ls -l /root/.cargo/bin/
total 101440
-rwxr-xr-x 10 root root 10383380 Feb 17 21:34 cargo
-rwxr-xr-x 10 root root 10383380 Feb 17 21:34 cargo-clippy
-rwxr-xr-x 10 root root 10383380 Feb 17 21:34 cargo-fmt
-rwxr-xr-x 10 root root 10383380 Feb 17 21:34 rls
-rwxr-xr-x 10 root root 10383380 Feb 17 21:34 rust-gdb
-rwxr-xr-x 10 root root 10383380 Feb 17 21:34 rust-lldb
-rwxr-xr-x 10 root root 10383380 Feb 17 21:34 rustc
-rwxr-xr-x 10 root root 10383380 Feb 17 21:34 rustdoc
-rwxr-xr-x 10 root root 10383380 Feb 17 21:34 rustfmt
-rwxr-xr-x 10 root root 10383380 Feb 17 21:34 rustup
root@2c3549fe3169:/sample# date
Sun Feb 17 21:34:21 UTC 2019
root@2c3549fe3169:/sample# file /root/.cargo/bin/cargo
/root/.cargo/bin/cargo: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.9, with debug_info, not stripped
root@2c3549fe3169:/sample# cargo
error: command failed: 'cargo'
info: caused by: No such file or directory (os error 2)

Он устанавливается через:

RUN curl https://sh.rustup.rs -sSf | sh -s -- \
--default-toolchain 1.32.0 \
-y && \
~/.cargo/bin/rustup target add i686-unknown-linux-musl && \
echo "[build]\ntarget = \"i686-unknown-linux-musl\"" > ~/.cargo/config

Я вижу файл, но не могу запустить его, даже когда переключаюсь в этот каталог:

root@2c3549fe3169:~/.cargo/bin# ./cargo
error: command failed: 'cargo'
info: caused by: No such file or directory (os error 2)

Это то, что я вижу, когда запускаю ldd:

root@4e21c8d37266:/volume# ldd /root/.cargo/bin/cargo
linux-gate.so.1 (0xf7f41000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf774c000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7742000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7723000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7705000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7529000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7427000)
/lib/ld-linux.so.2 (0xf7f43000)

Это мой полный Dockerfile

FROM i386/ubuntu

RUN apt-get update && apt-get install -y \
  cmake \
  curl \
  file \
  git \
  g++ \
  python \
  make \
  nano \
  ca-certificates \
  xz-utils \
  musl-tools \
  pkg-config \
  apt-file \
  xutils-dev \
  --no-install-recommends && \
  rm -rf /var/lib/apt/lists/*


RUN curl https://sh.rustup.rs -sSf | sh -s -- \
  --default-toolchain 1.32.0 \
  -y && \
  ~/.cargo/bin/rustup target add i686-unknown-linux-musl && \
  echo "[build]\ntarget = \"i686-unknown-linux-musl\"" > ~/.cargo/config


# Compile C libraries with musl-gcc
ENV SSL_VER=1.0.2j \
    CURL_VER=7.52.1 \
    CC=musl-gcc \
    PREFIX=/usr/local \
    PATH=/usr/local/bin:$PATH \
    PKG_CONFIG_PATH=/usr/local/lib/pkgconfig

RUN curl -sL http://www.openssl.org/source/openssl-$SSL_VER.tar.gz | tar xz && \
    cd openssl-$SSL_VER && \
    ./Configure no-shared --prefix=$PREFIX --openssldir=$PREFIX/ssl no-zlib -m32 linux-elf -fPIC -fno-stack-protector && \
    make depend 2> /dev/null && make -j$(nproc) && make install && \
    cd .. && rm -rf openssl-$SSL_VER

RUN curl https://curl.haxx.se/download/curl-$CURL_VER.tar.gz | tar xz && \
    cd curl-$CURL_VER && \
    ./configure --enable-shared=no --enable-static=ssl --enable-optimize --prefix=$PREFIX --host=i686-pc-linux-gnu CFLAGS=-m32 \
      --with-ca-path=/etc/ssl/certs/ --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt --without-ca-fallback && \
    make -j$(nproc) && make install && \
    cd .. && rm -rf curl-$CURL_VER

ENV SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt \
    SSL_CERT_DIR=/etc/ssl/certs \
    OPENSSL_LIB_DIR=$PREFIX/lib \
    OPENSSL_INCLUDE_DIR=$PREFIX/include \
    OPENSSL_DIR=$PREFIX \
    OPENSSL_STATIC=1 \
    PATH=/usr/local/bin:/root/.cargo/bin:$PATH

RUN echo $PATH

И связываю двоичный файл cargo согласно комментариям:

root@156da6108ff8:~/.cargo/bin# strace -f -e trace=execve cargo               
execve("/root/.cargo/bin/cargo", ["cargo"], 0xfffdd8fc /* 20 vars */) = 0
execve("/root/.rustup/toolchains/1.32.0-x86_64-unknown-linux-gnu/bin/cargo", ["/root/.rustup/toolchains/1.32.0-"...], 0x57d95620 /* 25 vars */) = -1 ENOENT (No such file or directory)
error: command failed: 'cargo'
info: caused by: No such file or directory (os error 2)
+++ exited with 1 +++

Answer 1

Итак, вот краткий обзор наших исследований.

Базовый образ, используемый для сборки, - i386/ubuntu с 32-битной средой внутри, однако это изображение не делает ничего, чтобы соответствующим образом замаскировать результаты uname(2) вызывает (имея в качестве точки входа что-то вроде setarch linux32), поэтому при работе в 64-битной системе (ваш случай) любой процесс внутри контейнера сборки, вызывающий uname(2) или uname(1), видит x86_64 вместо i686.Это корень проблемы.

Когда вы устанавливаете cargo, вы загружаете и запускаете скрипт установки, который определяет платформу, на которой он работает, и загружает соответствующую версию rustup-init.Обнаружение платформы в этом сценарии правильно распознает, что оно работает в 32-разрядной среде, но в 64-разрядном ядре, поэтому сценарий загружает 32-разрядную версию rustup-init.Однако rustup-init решает, что он работает на x86_64 (возможно, он видит x86_64, возвращаемый uname(2), но не выполняет проверку для случая "32-разрядная среда на 64-разрядном ядре", как сценарий установщика).делает).Вы можете видеть это во время установки без -y:

Current installation options:

    default host triple: x86_64-unknown-linux-gnu
    default toolchain: stable
    modify PATH variable: yes

Итак, rustup устанавливает 64-битный набор инструментов, и вы в конечном итоге сталкиваетесь с ситуацией, когда вызов cargo приводит к запуску 64-битовый двоичный файл в 32-битной среде , поэтому вы видите ошибку.

Я все еще чувствую какое-то противоречивое поведение здесь, потому что и установочный скрипт, и rustup-init являются частямитот же проект , и я не вижу причины, по которой они должны определять платформу по-разному в одной и той же среде (почему rustup-init не может быть таким же умным, как сценарий установки?).

Как заметил @Shepmaster, это известная проблема ( Rustup устанавливает 64-битный компилятор на 32-битный экземпляр Docker ).Возможны два обходных пути:

• принудительно назначить платформу для цепочки инструментов по умолчанию, передав --default-host i686-unknown-linux-gnu установщику;
• обмануть установщик, запустив его под setarch linux32 так, чтобы еговызов uname(2) будет видеть i686 вместо x86_64.

Лично я бы выбрал первый вариант, так как он кажется менее хакерским.