从 Ubuntu amd64 到 arm7l 进行交叉编译：exec 用户进程导致 "exec format error"
Go Cross Compilation from Ubuntu amd64 to arm7l : exec user process caused "exec format error"
我对从 amd64 到 arm7l 的交叉编译感到头疼
我终于可以用 Gitlab CI 做到这一点，所以现在，我在 docker 映像中编译我的二进制文件，这里是 docker 文件：
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
构建新容器 "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
在目标 OS 上，这是我得到的：
[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
当你运行在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 和一些实验性功能，因此其中有些部分不向后兼容，但希望对您有所帮助。我正在使用 multi-stage 构建来避免在 docker 之外进行编译，然后进行第二次构建。我还指定了构建主机的平台，并使用目标 arch 和 OS 变量来配置 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
要构建它，我可以 运行 one-off 使用 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 版本，它创建了一个 multi-arch 图像，将 运行 在多个平台上。这确实需要您推送到注册表服务器：
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 构建 multi-arch 图像的方法列表中的选项 3。
选项 1 是配置 qemu binfmt_misc 来构建和 运行 不同平台的图像。我还不能在 Linux 上用 Buildx 实现这个功能，但是 Docker 已经在 Mac 上做到了，你可以在Linux套件项目。如果您需要 运行 命令并在构建过程中安装其他工具，而不仅仅是交叉编译单个静态链接的二进制文件，那么根据您的情况使用 qemu 可能是理想的选择。
选项 2 运行 在目标平台上构建，如您所见，效果很好。使用 Buildx，您可以添加多个构建节点，每个平台最多一个，允许您从一个位置（CI 服务器）运行 构建。
我对从 amd64 到 arm7l 的交叉编译感到头疼
我终于可以用 Gitlab CI 做到这一点，所以现在，我在 docker 映像中编译我的二进制文件，这里是 docker 文件：
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
在目标 OS 上，这是我得到的：
[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
当你运行在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 和一些实验性功能，因此其中有些部分不向后兼容，但希望对您有所帮助。我正在使用 multi-stage 构建来避免在 docker 之外进行编译，然后进行第二次构建。我还指定了构建主机的平台，并使用目标 arch 和 OS 变量来配置 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
要构建它，我可以 运行 one-off 使用 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 版本，它创建了一个 multi-arch 图像，将 运行 在多个平台上。这确实需要您推送到注册表服务器：
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 构建 multi-arch 图像的方法列表中的选项 3。
选项 1 是配置 qemu binfmt_misc 来构建和 运行 不同平台的图像。我还不能在 Linux 上用 Buildx 实现这个功能，但是 Docker 已经在 Mac 上做到了，你可以在Linux套件项目。如果您需要 运行 命令并在构建过程中安装其他工具，而不仅仅是交叉编译单个静态链接的二进制文件，那么根据您的情况使用 qemu 可能是理想的选择。
选项 2 运行 在目标平台上构建，如您所见，效果很好。使用 Buildx，您可以添加多个构建节点，每个平台最多一个，允许您从一个位置（CI 服务器）运行 构建。