首页 > 解决方案 > 从 Ubuntu amd64 到 arm7l 进行交叉编译:exec 用户进程导致“exec 格式错误”

问题描述

我对从 amd64 到 arm7l 的交叉编译感到头疼

我终于可以用 Gitlab CI 完成了,所以现在,我在 docker 镜像中编译我的二进制文件,这里是 dockerfile:

FROM golang

WORKDIR /go/src/gitlab.com/company/edge_to_bc

COPY . .
RUN dpkg --add-architecture armhf && apt update && apt-get install -y gcc-arm-linux-gnueabihf libltdl-dev:armhf

我构建它然后我将构建新的容器“交叉编译”准备好名称ubuntu:cross-compil

现在,我可以编译我的二进制文件:

docker run -it -v ${EDGE_TO_BC_PATH}/release:/go/src/gitlab.com/company/edge_to_bc/release ubuntu:cross-compil  bash -c 'CC=arm-linux-gnueabihf-gcc CXX=arm-linux-gnueabihf-g++ CGO_ENABLED=1 GOOS=linux GOARCH=arm GOARM=7 go build -v -o ./release/edge_to_bc '

我可以看到我的可执行文件在./release/edge_to_bc

然后我构建我的 docker 镜像:

docker build -t registry.gitlab.com/company/edge_to_bc:armhf .

我推它。

在 Dockerfile 中,我只是从主机复制可执行文件:

FROM alpine:3.7

RUN apk --no-cache add ca-certificates libtool

WORKDIR /sunclient/

COPY ./release/edge_to_bc ./
EXPOSE 5555

CMD [ "./edge_to_bc" ]

但是当我在我的手臂板上运行它时:

docker run --rm registry.gitlab.com/company/edge_to_bc:armhf

我得到:

standard_init_linux.go:207: exec user process caused "no such file or directory"

调试时,如果我想获取文件列表

docker run --rm registry.gitlab.com/company/edge_to_bc:armhf

我得到:

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

这表明二进制仍然没有正确的格式......

我错过了什么 ?我在这个话题上花了很多时间,并没有更多的想法。

当我检查二进制的体系结构时,这就是我得到的:

 edge_to_bc git:(master) ✗ readelf -h ./release/edge_to_bc
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x19209
  Start of program headers:          52 (bytes into file)
  Start of section headers:          23993360 (bytes into file)
  Flags:                             0x5000400, Version5 EABI, hard-float ABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         10
  Size of section headers:           40 (bytes)
  Number of section headers:         49
  Section header string table index: 48

在目标操作系统上,这就是我得到的:

[root@gw-sol1 ~]# uname -a
Linux gw-sol-1 4.4.113-UNRELEASED #1 SMP PREEMPT Thu Mar 7 16:46:40 CET 2019 armv7l armv7l armv7l GNU/Linux

编辑:

当我直接在 ARM 设备上构建应用程序时,它将工作:

go build -o ./release/edge_to_bc -v -ldflags '-w -s -extldflags "-static"' ./...

精灵:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - GNU
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x125f1
  Start of program headers:          52 (bytes into file)
  Start of section headers:          16594072 (bytes into file)
  Flags:                             0x5000400, Version5 EABI, hard-float ABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         7
  Size of section headers:           40 (bytes)
  Number of section headers:         38
  Section header string table index: 37

它似乎与另一个非常相似,至少在建筑方面。

然后构建 docker 镜像:

docker build . -t image/peer-test:armhf

标签: dockergoarmcross-compiling

解决方案


当您使用以下命令在 arm7 映像的 amd64 系统上运行构建时:

docker build -t registry.gitlab.com/company/edge_to_bc:armhf .

它将使用基础映像并在该映像中为 amd64 运行命令。因此,即使您的单个edge_to_bc二进制文件可能被交叉编译,图像的其余部分也不是。接下来,二进制编译命令本身看起来像是链接到库,而这些库很可能不在您的最终映像中。您可以运行ldd edge_to_bc以查看这些链接,如果它们丢失,您将收到文件未找到错误。


在我自己的交叉编译测试中,我在 19.03.0-rc2 上使用了 BuildKit、Buildx 和一些实验性功能,因此其中会有部分不向后兼容,但希望对您有所帮助。我正在使用多阶段构建来避免在 docker 之外进行编译,然后再进行第二次构建。我还指定了构建主机的平台,并使用目标架构和操作系统变量来配置 go 以进行交叉编译。在这种情况下,我使用了一个完全静态链接的二进制文件,因此没有要包含的库,并且在我的最终发布映像中只使用了复制命令,我避免了在不同平台上运行构建的问题。

# syntax=docker/dockerfile:experimental
# ^ above line must be at the beginning of the Dockerfile for BuildKit

# --platform pulls an image for the build host rather than target OS/Arch
FROM --platform=$BUILDPLATFORM golang:1.12-alpine as dev
RUN apk add --no-cache git ca-certificates
RUN adduser -D appuser
WORKDIR /src
COPY . /src/
CMD CGO_ENABLED=0 go build -o app . && ./app

# my dev stage is separate from build to allow mounting source and rebuilding
# on developer machines    
FROM --platform=$BUILDPLATFORM dev as build
ARG TARGETPLATFORM
ARG TARGETOS
ARG TARGETARCH
# --mount is an experimental BuildKit feature
RUN --mount=type=cache,id=gomod,target=/go/pkg/mod/cache \
    --mount=type=cache,id=goroot,target=/root/.cache/go-build \
    CGO_ENABLED=0 GOOS=${TARGETOS} GOARCH=${TARGETARCH} \
    go build -ldflags '-w -extldflags -static' -o app .
USER appuser
CMD [ "./app" ]

# this stage will have the target OS/Arch and cannot have any RUN commands
FROM scratch as release
COPY --from=build /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=build /etc/passwd /etc/group /etc/
COPY --from=build /src/app /app
USER appuser
CMD [ "/app" ]

FROM scratch as artifact
COPY --from=build /src/app /app

FROM release

为了构建它,我可以使用 BuildKit 运行一次性构建命令:

DOCKER_BUILDKIT=1 docker build --platform=linux/amd64 -f Dockerfile -t golang-app:amd64 .
DOCKER_BUILDKIT=1 docker build --platform=linux/arm64 -f Dockerfile -t golang-app:arm64 .

但更好的是 Buildx 版本,它创建了一个可以在多个平台上运行的多架构映像。这确实需要您推送到注册表服务器:

docker buildx build -f Dockerfile --platform linux/amd64,linux/arm64 \
  -t ${docker_hub_id}/golang-app:multi-arch --output type=registry .

对于您的场景,您可以将 arm64 中的引用换成您自己的架构。该--platform选项在我运行的许多命令中被列为实验性选项,因此您可能需要在 /etc/docker/daemon.json 文件中配置以下内容以启用:

{ "experimental": true }

我相信这需要完全重启 docker 守护进程(systemctl restart docker),而不仅仅是重新加载,才能生效。

为了从构建中提取工件(特定架构的编译二进制文件),我使用:

docker build -f Dockerfile --target artifact -o type=local,dest=. .

这会将工件阶段的内容(单个二进制文件)输出到本地目录。


以上是 Docker 构建多架构镜像的方法列表中的选项 3。

选项 1 是使用 binfmt_misc 配置 qemu 以构建和运行不同平台的映像。我还不能用 Buildx 让它在 Linux 上运行,但是 Docker 已经在 Mac 上完成了这个,你可以找到更多关于他们在 LinuxKit 项目中所做的事情的详细信息。如果您需要运行命令并安装其他工具作为构建的一部分,而不仅仅是交叉编译单个静态链接的二进制文件,那么根据您的情况使用 qemu 可能是理想的。

选项 2 是在目标平台上运行构建,正如您所见,它运行良好。使用Buildx,您可以添加多个构建节点,每个平台最多一个,允许您从单个位置(CI 服务器)运行构建。


推荐阅读