dockerfile中的RUN命令产生的结果与在容器内手动运行相同命令的结果不同

Question

我正在创建一个具有gcc 4.8.5的Ubuntu 12.04 docker镜像。 我正在获取gcc 4.8.5源代码并自己构建它。 该容器将在Ubuntu 18.04主机上运行。

引用底部的代码，如果我没有把它放在dockerfile中并在启动容器后运行相同的命令，那么构建工作正常，但是如果我在dockerfile中使用RUN，我会得到以下构建错误

In file included from /usr/include/stdio.h:28:0,
             from ../../../gcc-4.8.5/libgcc/../gcc/tsystem.h:87,
             from ../../../gcc-4.8.5/libgcc/libgcc2.c:27:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such 
file or directory
#include <bits/predefs.h>
                      ^

问题似乎源于./gcc-4.8.5/configure调用。 当在容器内运行时，我得到：

checking build system type... i686-pc-linux-gnu

当放入dockerfile我得到：

checking build system type... x86_64-unknown-linux-gnu

有人可以在dockerfiles中填写我对RUN的理解，因为我觉得我错过了它的工作方式。 我的印象是这些命令会在前一层运行吗？ 但似乎他们正在我的主机上运行。

## Get gcc 4.8.5 and build it
RUN wget ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.8.5/gcc-4.8.5.tar.gz \
&& tar xzf gcc-4.8.5.tar.gz && \
cd gcc-4.8.5 && \
./contrib/download_prerequisites && \
cd .. && mkdir gccbuild && cd gccbuild && \
../gcc-4.8.5/configure \
--prefix="/opt/gcc" \
--enable-shared --with-system-zlib --enable-threads=posix \
--enable-__cxa_atexit --enable-checking --enable-gnu-indirect-function \
--enable-languages="c,c++" --disable-bootstrap \
&& make all && make install 

编辑：

docker build -t 12.04_builder - < dockerfile
docker run -i -t 12.04_builder

完整的dockerfile：

FROM jnickborys/i386-ubuntu:12.04

RUN apt-get update && \ 
    apt-get install -y \ 
      wget \
      build-essential \
      libssl-dev \
      git \
      asciidoc \
      libpulse-dev \
      libasound2-dev \
      libpcsclite-dev 

## Get latest cmake that has a 32-bit version
RUN wget https://github.com/Kitware/CMake/releases/download/v3.6.3/cmake-3.6.3-Linux-i386.sh && \ 
    chmod +x cmake-3.6.3-Linux-i386.sh && \ 
    ./cmake-3.6.3-Linux-i386.sh --skip-license --prefix=/usr

## Get gcc 4.8.5 and build it
RUN wget ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.8.5/gcc-4.8.5.tar.gz \
    && tar xzf gcc-4.8.5.tar.gz && \
    cd gcc-4.8.5 && \
    ./contrib/download_prerequisites && \
    cd .. && mkdir gccbuild && cd gccbuild && \
    ../gcc-4.8.5/configure \
    --prefix="/opt/gcc" \
    --enable-shared --with-system-zlib --enable-threads=posix \
    --enable-__cxa_atexit --enable-checking --enable-gnu-indirect-function \
    --enable-languages="c,c++" --disable-bootstrap 
    && make all && make install

Answer 1

首先，一点背景：在构建期间运行的平台检测脚本使用uname(1)实用程序（因此uname(2)系统调用）来识别它运行的硬件：

root@6e4b69adfd4c:/gcc-4.8.5# grep 'uname -m' config.guess 
UNAME_MACHINE=`(uname -m) 2>/dev/null` || UNAME_MACHINE=unknown

在64位计算机上， uname -m返回x86_64 。 但是，有一个系统调用允许覆盖此结果： personality(2) 。 当进程调用personality(2) ，它及其后续的forks（children）在调用uname(2)时开始看到假结果。 因此，有可能要求内核在uname(2)提供虚假的硬件信息。

您使用的基本映像（ jnickborys/i386-ubuntu:12.04 ）包含32位二进制文​​件并定义入口点/usr/bin/linux32 ，它调用personality(PER_LINUX32)以要求内核假装它在32位上运行硬件并以uname(2)返回i686 （这可以分别使用docker inspect和strace进行检查）。 这使得可以假装容器化过程在32位环境中运行。

在RUN指令中执行构建和在容器中手动执行构建有什么区别？

在RUN执行构建时，Docker不使用入口点来运行命令。 它使用SHELL指令中指定的内容（默认为/bin/sh -c ）。 这意味着运行构建的shell的个性不会改变，它（和子进程）会看到真正的硬件信息 - x86_64 ，因此，您可以在32位环境中获得x86_64-unknown-linux-gnu构建系统类型并且构建失败。

当您在容器中手动运行构建时（例如，在使用docker run -it jnickborys/i386-ubuntu:12.04启动它然后执行与Dockerfile中相同的步骤之后），将调用入口点，从而改变个性，并且内核开始报告它在32位硬件（ i686 ）上运行，因此您获得了i686-pc-linux-gnu构建系统类型，并且构建正确运行。

如何解决这个问题？ 取决于你想要什么。 如果您的目标是为64位环境构建gcc，则只需使用64位基本映像。 如果要构建32位环境，可以选择在这些RUN之前更改用于RUN的SHELL ：

SHELL ["/usr/bin/linux32", "/bin/sh", "-c"]

这将使Docker执行具有改变个性的RUN ，因此，将正确检测构建系统类型（ i686-pc-linux-gnu ）并且构建将成功。 如果需要，您可以在构建后将SHELL更改回/bin/sh -c 。