gpt4 book ai didi

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

转载 作者:太空狗 更新时间:2023-10-29 11:17:01 25 4
gpt4 key购买 nike

我正在创建一个具有 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

最佳答案

首先,一些背景知识:在构建期间运行的平台检测脚本使用 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) 时,它和它的后续分支(子进程)在调用 uname(2) 时开始看到伪造的结果。因此,有可能要求内核在 uname(2) 中提供伪造的硬件信息。

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

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

当您在 RUN 中执行构建时,Docker 不会使用入口点来运行命令。它改用 SHELL 指令中指定的内容(默认为 /bin/sh -c)。这意味着运行构建的 shell 的特性没有改变,它(和子进程)看到真实的硬件信息 - x86_64,因此,你得到 x86_64-unknown-linux -gnu 32位环境构建系统类型,构建失败。

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

如何解决这个问题?取决于你想要什么。如果您的目标是为 64 位环境构建 gcc,只需使用 64 位基础镜像。如果您想为 32 位环境构建,您的选择之一是在这些 RUN 之前更改用于 RUNSHELL :

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

这将使 Docker 以改变的特性执行 RUN,因此,将正确检测构建系统类型 (i686-pc-linux-gnu) 和构建将会成功。如果需要,您可以在构建后将 SHELL 改回 /bin/sh -c

关于linux - dockerfile 中的 RUN 命令产生的结果与在容器中手动运行相同命令产生的结果不同,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/54416100/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com