答案是交叉编译器本身架构不匹配：arm-linux-gcc 必须是宿主机（如x86_64）可执行文件，若 file 显示其为 ARM/aarch64 格式，则下载错误；正确版本应带 x86_64- 前缀或明确标注“Linux x86_64”。
交叉编译器本身架构不匹配
报 cannot execute binary file: Exec format error，第一反应不该是“代码有问题”，而是检查 arm-linux-gcc 这个文件自己能不能跑。它必须是宿主机架构（比如 x86_64）的可执行文件，而不是目标机（如 aarch64）的。
用 file arm-linux-gcc 看输出：如果显示 ELF 64-bit LSB pie executable, ARM aarch64，说明你下错了——这是给 ARM 主机用的原生编译器，不是交叉编译器。
- 正确版本名通常含
x86_64-前缀，例如x86_64_aarch64-linux-gnu-gcc或gcc-arm-linux-gnueabihf（x86_64 安装包） - 优先从 ARM 官方 GNU Toolchain 页面下载 “Linux x86_64” 版本，别选 “AArch64 Linux”
- 解压后立刻执行
file ./bin/arm-linux-gcc验证，确认是ELF 64-bit LSB pie executable, x86-64
生成的程序在目标板上运行时报Exec format error
这说明交叉编译器工作正常，但产出的二进制仍无法执行。常见原因不是指令集错，而是 ABI 或动态链接器路径不兼容。
先在目标板上运行 file ./your_program，确认输出里有 ARM aarch64 或 ARM；再查 readelf -l ./your_program | grep interpreter，看 INTERP 段指定的动态链接器（如 /lib/ld-linux-aarch64.so.1）是否存在、是否匹配目标系统。
- 目标板若用 musl libc（如 Alpine），而你用 glibc 工具链编译，就会因链接器不识别而失败
- 某些 SDK 自带 sysroot，但没把
ld-linux-*.so.*放进目标板的/lib目录，需手动复制 - 避免用
-static以外的方式依赖系统级库，除非你完全控制目标板的 rootfs
CMake/Makefile 中交叉编译配置漏掉关键参数
即使工具链路径对了，CMake 或 Makefile 若没显式指定目标平台，GCC 会默认按宿主机环境找头文件和库，导致链接或运行时出问题。
典型错误是只设了 CC=arm-linux-gcc，却没配 --sysroot 和 -march/-mabi。结果可能编译通过，但 stdio.h 来自宿主机，生成的二进制调用的是 x86 的 libc 符号。
- CMake 中必须传
-DCMAKE_SYSROOT=/path/to/arm/sysroot，且该目录下要有usr/include和usr/lib - Makefile 中推荐写成：
CC = arm-linux-gcc --sysroot=$(SYSROOT) -march=armv8-a -mabi=lp64 - 用
arm-linux-gcc -v查看默认 sysroot 路径，再核对它是否真实存在、是否包含目标平台的libc.so
Docker 构建阶段出现Exec format error
不是容器运行时报错，而是在 Dockerfile 的 RUN 阶段就失败，比如 RUN ./build.sh 报错，说明这个 build.sh 或其调用的工具是错架构的。
尤其注意：Docker 构建上下文里混入了本地编译的脚本或二进制（比如你在 Mac M1 上生成的 arm64 build 工具），然后 COPY 进 x86_64 构建镜像里执行——内核直接拒载。
- 所有被
COPY进构建阶段的可执行文件，都得是amd64架构（除非你明确用buildx多平台构建） - 避免在 Dockerfile 中
RUN curl ... && chmod +x && ./tool，除非确认tool是多架构或宿主架构匹配 - CI 场景下，用
uname -m打印构建节点架构，再决定拉哪个版本的预编译工具
真正卡住人的，往往不是 GCC 参数记不全，而是把“交叉编译器”和“目标平台二进制”这两层架构混淆了——前者必须跑在你键盘前的机器上，后者才该躺在开发板的 /usr/bin 里。每次遇到 Exec format error，先问一句：出错的是谁？是你敲命令的 shell，还是你拷过去的程序？答案不同，排查路径完全不同。
