“x86电脑能编译ARM程序”这个标题我第一眼看到的时候心里想的是这不是基础得不能再基础的常识吗后来发现问的人多了才意识到很多朋友刚接触嵌入式或者ARM开发时脑子里一直有个坎儿迈不过去——我用的明明是Intel的CPU写出来的程序怎么就能跑到手机、开发板那种ARM芯片上感觉像在北京做的川菜却端到了成都的餐桌上怎么想怎么不对劲。这个问题的答案其实藏在“编译”和“运行”的分离上。CPU架构只决定最终产物跑在什么机器上而编译这个动作本身只是在一个平台上执行一个翻译软件而已。这台“翻译软件”只要能在x86上跑起来它产出的目标文件是ARM格式的这一点都不矛盾。这就好比你用中文写了一份日文菜单菜单是用中文写的注释但菜品名称全是日文日本人拿到照样能点菜。编译器的源码、编译器本身、编译产物这三者的架构完全不要求一致这才是交叉编译能成立的根本前提。这篇内容我会从指令集和编译原理的角度把这件事彻底讲透再结合这些年做ARM Linux移植、嵌入式Linux应用开发、Qt交叉编译踩过的坑给出一套从零开始的交叉编译实操流程。适合刚接触嵌入式开发、做ARM平台移植、或者面试前想搞清楚编译原理底层逻辑的同学。1. 先厘清底层概念指令集、CPU架构与可执行文件的关系1.1 CPU架构就是“方言体系”指令集是底层词汇要理解为什么x86电脑能编译ARM程序先得把CPU的本质看清楚。CPU这东西本质上就是一个死板的执行器——它不认什么C语言、Java、Python只认自己的机器码。机器码是一串二进制每个二进制组合对应一个基本操作比如“把内存某个地址的数据搬到寄存器”“把两个寄存器里的数相加”“跳转到某个地址继续执行”。这一整套基本操作的二进制编码规则就叫指令集架构Instruction Set ArchitectureISA。x86和ARM的区别就在于这两套ISA完全不同。x86是复杂指令集CISC的典型代表指令长短不一、功能复杂一条指令能做的事情非常多历史上为了兼容性背了很重的包袱ARM是精简指令集RISC的典型代表指令定长ARM模式固定32位Thumb模式固定16位、规则整齐大多数指令只能做一件简单的事。更直观的差异是寄存器数量x86的通用寄存器数量少而ARM在标准模式下有一大排通用寄存器。这些底层的设计差异决定了同一段C代码在两种架构下会被编译成完全不同的机器指令序列。你写一句int sum a bx86编译出来可能是mov eax, [ebp-4]; add eax, [ebp-8; mov [ebp-12], eax]而ARM编译出来可能是ldr r0, [sp, #4]; ldr r1, [sp, #8]; add r0, r0, r1; str r0, [sp, #12]。看到没寄存器名都不同。直接把x86的二进制扔到ARM芯片上ARM会傻掉——它根本不知道eax是什么东西。1.2 可执行文件就是“一本写死的操作手册”我们平时说的编译就是把高级语言翻译成目标机器的操作手册。这个手册用的是哪种方言取决于你在编译时指定的目标架构而不是你当前用的电脑。这里有个关键认知可执行文件不是一个“程序本体”而是一份“指令清单数据清单”的打包文件。Windows的PE格式、Linux的ELF格式本质上都是容器里面装着目标架构能识别的机器指令。你用x86电脑编译ARM程序就是把指令清单用ARM的方言写好打包成ELF格式之后传到ARM板子上解包执行。编译那台电脑是什么架构和清单用什么方言写这两件事没有半毛钱关系。其实最典型的例子就是汇编器。你现在用的任何一款x86电脑上都装着能生成x86代码的编译器但你也可以通过添加目标说明让编译器生成ARM、RISC-V、MIPS等架构的代码。编译器不过是一个普通程序它怎么生成代码取决于它的内部实现里包含了几套“方言翻译规则”而不是它运行在什么CPU上。2. 交叉编译的核心逻辑为什么能在一个平台上为另一个平台产出程序2.1 编译四个阶段里到底哪一步涉及“架构”先朴素地过一遍编译流程预处理预处理器展开宏和头文件、编译把C/C翻译成汇编、汇编把汇编翻译成目标文件也就是机器码、链接把多个目标文件和库合并成最终可执行文件。注意看真正决定产物架构的是“汇编”这一步。编译器把C代码翻译成汇编文本时就已经按照目标架构的规则生成了对应的指令比如用ldr还是mov eax。随后汇编器把这些文本指令翻译成二进制机器码。所以编译器的“后端”决定了程序跑在什么架构上。这里就引入两个术语宿主机Host和目标机Target。宿主机是你当前用来干活的机器也就是x86电脑目标机是编译产物最终要运行的机器也就是ARM开发板。本地编译是Host与Target相同交叉编译是Host与Target不同。x86电脑编译ARM程序就是典型的交叉编译。2.2 打破直觉的一个事实编译器本身也是程序为什么很多人觉得x86不能编译ARM是因为潜意识里把“编译”想象成了CPU在“思考”怎么生成指令。其实编译器就是一个跑在x86上的普通程序它只是消耗CPU和内存资源。它内部挂载了ARM后端的代码生成逻辑执行到这步时会按照ARM的规则输出指令文本和二进制。它不要求CPU“懂ARM”只要求它自身能在x86上运行。打个比方一个译员他是中国人运行在x86上但他精通日语ARM指令集他能把中文小说C代码翻译成日文ARM机器码。翻译出来的书是日本人读的但这不影响译员自己生活在北京。编译器的角色就是那个译员x86架构是他生活的环境ARM汇编是他掌握的语言而编译一次就等于翻译一本新书。2.3 为什么交叉编译必须单独准备工具链因为编译器的“后端”通常是独立于“前端”的但标准的系统编译器在构建时只启用了一个目标后端。你要让x86电脑产生ARM代码就得用专门的交叉编译工具链比如arm-linux-gnueabihf-gcc。这套工具链是完整编译器的变体——它运行在x86上但默认目标架构是ARM。可能你会问为什么不直接用普通的gcc加个参数指定架构实际上gcc确实支持-march、-mabi这些选项但那只适用于同一个体系内的微调比如x86的-marchnative、-m32这种。真正跨架构编译时你需要的不仅是编译器本身还有人头文件、标准库的ARM版、链接器、汇编器这一整套东西在普通gcc里并不齐备。交叉工具链就是把这些打包好了的一套完整环境。3. 实操在x86电脑上搭建ARM交叉编译环境并编译出一个能跑的ARM程序3.1 工具链选型哪些交叉编译器最常见做ARM交叉编译第一个问题是用什么工具链。我见过很多新手在这里踩坑装了个工具链名字看着对结果编译出来的程序架构不对或者在板子上跑不起来。常见的几类工具链有这些arm-linux-gnueabihf-gcc最经典的ARM Linux交叉编译器。这是针对32位ARM架构、使用硬浮点hard-floatABI的工具链可以编译ARM Linux用户态程序生成的程序跑在装有Linux的ARM板子上。aarch64-linux-gnu-gcc64位ARMAArch64的交叉编译器编译出来的程序跑在ARMv8架构的64位Linux系统上比如树莓派的64位系统、大部分手机Linux发行版、一些服务器。arm-none-eabi-gcc不依赖操作系统的裸机交叉编译器。编译出来的程序不带Linux内核依赖直接烧录到单片机或者裸机ARM板上。这类工具链生成的程序没有操作系统概念适用场景是STM32这些裸机开发。ARM Compiler 5.06 / 6.x官方提供的商用编译器Keil MDK里默认集成的就是ARM Compiler 5.06。这个在嵌入式开发领域用得非常多后面我会单独说。我平时做ARM Linux应用层开发用得最多的是arm-linux-gnueabihf-gcc和aarch64-linux-gnu-gcc。如果是给树莓派64位系统编程序就用aarch64如果是给32位ARM开发板跑Linux就用arm-linux-gnueabihf。3.2 Linux环境下的交叉编译工具链安装在Ubuntu或者Debian系Linux上安装交叉工具链非常简单一条命令就搞定sudo apt update sudo apt install gcc-arm-linux-gnueabihf binutils-arm-linux-gnueabihf如果要编64位的就装sudo apt install gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu装好之后用arm-linux-gnueabihf-gcc --version验证能看到正常的版本信息就说明工具链装好了。这套工具链安装后会在/usr/bin/下生成一系列交叉工具包括编译器、汇编器、链接器、二进制工具arm-linux-gnueabihf-objdump、arm-linux-gnueabihf-readelf、arm-linux-gnueabihf-strip这些工具后面排查问题都要用到。有时候你还得装对应架构的标准库。很多发行版提供了跨架构的库包比如Debian系可以通过dpkg --add-architecture armhf来添加ARM架构软件源然后用apt install libc6-dev:armhf来安装ARM版本的标准库开发文件。这一步骤在做大型项目交叉编译时特别关键因为头文件和库文件都必须是对应目标架构的版本。3.3 Windows环境下的交叉编译工具链配置如果你的主力环境是Windows也完全可以做交叉编译。最靠谱的做法是用WSLWindows Subsystem for Linux安装一套Ubuntu然后在Ubuntu里按上面步骤安装交叉工具链。这个方案的好处是环境干净不污染Windows系统而且交叉编译本身对性能要求不高WSL2的I/O性能足够应付绝大部分项目。如果不想用WSL也可以直接下载独立的交叉编译工具链。ARM官方提供了GNU ARM Toolchain里面有Windows版本下载解压后把bin目录加入PATH就行。另外很多厂商也提供自己的交叉编译工具链比如在Windows上用Keil MDK做STM32开发本质上就是用了一套Windows环境下的ARM编译器。这里我想插一个特别的坑。Windows环境下经常有人把交叉编译器装好之后发现命令行根本跑不了报错提示是PowerShell禁止运行脚本。这个报错跟交叉编译本身无关但拦截率极高。错误信息长这样npm : 无法加载文件 D:\Program Files (x86)\nodejs\npm.ps1因为在此系统上禁止运行脚本这是因为PowerShell默认的执行策略是Restricted不允许执行任何.ps1脚本。解决办法就是临时放开当前用户的执行策略Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser之后重新打开终端就能执行npm和各类脚本了。这个坑在Windows环境做任何开发都会遇到第一次碰到记得先想到执行策略。3.4 最小实例编译一个ARM版Hello World工具链装好了我们来实战验证一下交叉编译是怎么回事。写一个最简单的C程序文件名为hello.c#include stdio.h int main(void) { printf(Hello, ARM!\n); return 0; }先用本地编译器编译一份x86版本gcc hello.c -o hello_x86 file hello_x86file命令会显示可执行文件的架构信息你看到的应该是类似“ELF 64-bit LSB pie executable, x86-64”的字样。然后咱们用交叉编译器来编译arm-linux-gnueabihf-gcc hello.c -o hello_arm file hello_arm这次file命令显示的结果就不一样了ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0看到“ARM, EABI5”这个字样就说明编译成功了——在你的x86电脑上产出的是一个ARM机器码的ELF文件。如果在本地试着直接运行./hello_arm会报“Exec format error”这个错误就直观地说明当前x86内核不认识ARM的机器码。3.5 怎么验证编译产物确实能在ARM上运行有一种快速验证的方法不用真板子可以用QEMU模拟ARM环境。Ubuntu下装个qemu-user就能直接跑ARM用户态程序sudo apt install qemu-user ./hello_arm如果一切正常你会看到终端打印Hello, ARM!。这里面qemu-user做的就是在x86系统上模拟ARM的CPU执行环境把ARM机器码一条条翻译成x86能执行的指令。这不是编译是模拟执行但是用来快速验证交叉编译产物是否可用特别方便。要验证产物里的动态库依赖可以用交叉编译器自带的readelf比如arm-linux-gnueabihf-readelf -d hello_arm它会列出这个ARM可执行文件依赖的动态库。如果交叉编译时动态库路径配置不对这里就能看出问题。4. 链接器、运行时库与ABI交叉编译里最阴险的坑都在这一层4.1 编译只是第一步ABI不一致照样跑不起来很多新手第一次成功编译出ARM程序后很兴奋结果传到开发板上一跑直接报“No such file or directory”。看着文件明明在怎么会找不到其实这个报错经常是动态链接器路径的问题。交叉编译出来的程序里写死了动态链接器的路径比如ARM硬浮点程序的动态链接器是/lib/ld-linux-armhf.so.3。如果你的板子上的根文件系统里没有这个文件或者用的是软浮点工具链路径对不上系统就报这个错。这里就涉及ABIApplication Binary Interface的概念。ABI是一套完整的二进制接口规范包括函数参数怎么传用寄存器还是栈、浮点参数怎么传用通用寄存器还是专用浮点寄存器VFP/NEON、结构体怎么对齐、系统调用怎么触发。两个程序就算CPU架构相同ABI不一致也没法互相兼容。ARM写Linux程序常见的ABI有软浮点soft-float和硬浮点hard-float。软浮点用通用寄存器传浮点参数硬浮点用VFP寄存器传。arm-linux-gnueabi-gcc生成的是软浮点程序arm-linux-gnueabihf-gcc生成的是硬浮点程序。如果你用软浮点工具链编译程序试图链接硬浮点的库链接器会直接报“selected processor does not supportvfpv3”这类的错误。所以选工具链时一定要明确目标系统的ABI否则调半天都不知道问题在哪。4.2 库文件也必须是对应架构的版本交叉编译时链接动态库-L指定的目录和-l指定的库名的格式这些库文件本身必须得是ARM架构的。如果你不小心链接了一个x86的.so文件链接器会报非常经典的错误skipping incompatible /usr/lib/libxxx.so when searching for -lxxx这个“skipping incompatible”翻译成人话就是我找到了一个库文件但它的格式跟目标机架构不匹配我跳过它。凡是看到这个报错先检查库的架构。用file命令查看库文件的架构信息file libxxx.so如果显示的是“x86-64”而不是“ARM”那就说明你的链接路径写错了找错库了。这也是交叉编译最折磨人的问题之一——库文件架构不匹配往往不会以直接报错的形式暴露而是要么skipping incompatible要么链接时根本找不到符号要么运行时提示动态库不存在。我自己处理这类问题时的经验是遇到链接错误第一反应不要只盯着库名先file一下库文件。如果项目是用CMake组织的还要检查CMAKE_SYSROOT和CMAKE_PREFIX_PATH的设置确保CMake优先在交叉编译的sysroot目标系统根目录下去找库而不会找到宿主机自带的x86库。4.3 静态库链接的隐藏炸弹动态库架构不匹配时会直接报错跳出来但静态库.a文件有个更阴险的情况。.a文件本质上是一个目标文件.o文件的归档包。链接时交叉编译器会把.a文件当做一个XX格式的目标文件来解析。如果你不小心给了它一个x86的.a文件编译器可能会直接把它当空归档文件处理慢慢查出问题。实际上GNU的链接器在解析.a的成员时也会做架构匹配检查。如果.a文件里的某个目标文件是x86的链接器还是能认出来。但有些老版本的链接器或某些特殊情况下报错信息可能不是特别明确让人以为是自己代码问题。所以只要是从第三方下载的静态库用之前务必跑一次arm-linux-gnueabihf-ar t libfoo.a arm-linux-gnueabihf-objdump -a libfoo.a看看里面目标文件的架构是不是ARM。这也是为什么厂商提供的SDK里通常有不同架构的库文件目录lib_armhf、lib_aarch64、lib_x86_64选错目录是家常便饭。4.4 大型项目交叉编译Qt、OpenCV的基本思路如果只是编译几个C文件交叉编译很快就能搞定。但实际工程中经常遇到Qt、OpenCV这类大型依赖库。这时候的核心思路是先用自己的交叉工具链把依赖库完整编译出ARM版本再在编译项目时指定使用这些ARM版本的头文件和库。以Qt为例你需要在x86电脑上用交叉工具链配置并编译Qt源码得到一套ARM版的Qt库。这个过程对新手来说确实繁琐涉及配置qmake.conf、设置交叉编译前缀、指定opengl或者eglfs这几个平台插件。我做过一次完整的根文件系统移植整个Qt库编译加安装大概花了两三个小时中间因为各种依赖报错反复调整配置。但编译完之后后续项目的交叉编译就变成了标准的“指定Qt路径调用交叉qmake”的流程。如果项目不是特别复杂也可以考虑用Docker构建一个包含交叉编译工具链和依赖库的镜像让整个编译环境可移植。这个方法在团队协作时尤其好用每个人拉同一个镜像编译环境完全一致很多“在我电脑上能编在你电脑上报错”的玄学问题直接消失。5. 常见交叉编译工具与IDE的交叉编译配置5.1 ARM Compiler 5.06为什么还这么流行热词里有不少人在搜arm compiler 5.06这让我很感慨。ARM Compiler 5.06 Update 7build 960是很多嵌入式工程师又爱又恨的东西。爱是因为它稳定兼容性好Keil MDK项目里的大量老代码都是用它编译的恨是因为它在新版本的Windows和IDE环境上经常出兼容性问题。ARM Compiler 5.06是32位的编译器安装目录通常在C:\Keil_v5\ARM\ARMCC\bin核心工具是armcc、armasm、armlink、fromelf。这些老工具的优势是对C99的支持非常好编译出来的代码体积小、稳定性高非常适合MCU级别Cortex-M系列的开发。很多人搜“arm compiler 5.06下载”通常是因为新装的Keil MDK默认带了AC6基于Clang但老工程必须用AC5编译不得不再补装。我当年在项目里就踩过这样一个坑工程用的芯片是Cortex-M4有大量低版本的老代码用AC6编译各种告警和错误换回AC5一口气编译通过。这就是为什么呼叫ARM Compiler 5.06的人越来越多——工程兼容性决定了工具链选型。5.2 在Eclipse、Visual Studio、CLion里配置交叉编译现在跨平台的IDE基本上都支持自定义工具链。以Eclipse为例在Project Properties - C/C Build - Settings里把gcc(编译器)和g(编译器)替换成交叉编译器的路径和名称再把头文件搜索路径加到交叉编译器对应的sysroot下。CLion和VSCode的标准做法是在CMake工具链中配置交叉编译器。CMake有个专门支持交叉编译的机制通过CMake工具链文件toolchain file来指定编译器、系统根目录和目标平台。一个最简的ARM toolchain文件写法如下set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc) set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g) set(CMAKE_SYSROOT /path/to/arm/sysroot) set(CMAKE_FIND_ROOT_PATH /path/to/arm/sysroot) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)这段配置的含义是告诉CMake目标系统是Linux on ARM编译器用交叉编译器头文件和库都在你指定的sysroot路径里找。最后三个MODE设置很关键PROGRAM设为NEVER是让CMake在宿主机上找程序比如编译器本身LIBRARY和INCLUDE设为ONLY是让CMake绝对不要在宿主机路径里找头文件和库这样就不会出现误链到x86库的问题。配置好后在IDE里选择这个CMake工具链点击构建就会自动调用交叉编译器。我推荐新手用CLion或VS CodeRemote之类的组合来做交叉编译因为它们的CMake支持更完善错误提示也直观。5.3 不用交叉编译的“懒人方案”如果不想在x86电脑上搭交叉编译环境还有几种替代方案。第一种是直接在ARM板子上编译——如果板子性能够用直接在板上装GCC再把源码拷过去编译。这种方法最保险但效率低而且很多资源紧张的嵌入式板子根本跑不动完整编译。第二种方案是在x86电脑上用QEMU启动一个ARM架构的虚拟机或用户态环境在模拟出来的ARM环境里编译。这种方式编译生成的产物和目标系统完全一致缺点是编译速度比纯交叉编译慢不少。第三种方案是使用Docker容器配合arm平台的镜像。从2022年开始新版Docker Desktop天然支持跨架构镜像运行能直接在x86电脑上跑ARM的Docker容器原理是用QEMU实现指令翻译然后在这个容器里编译代码。这种方法特别适合验证依赖多、系统库版本复杂的项目。要注意的是这类模拟方案虽然方便但它跟纯交叉编译是两码事。交叉编译生成ARM的代码但不会执行它而模拟方案是在x86电脑上实际运行ARM代码。前者速度更快后者兼容性检查更彻底两者各有适用场景。6. 交叉编译常见问题与排查实录6.1 Windows下脚本执行与工具链路径问题做交叉编译最常踩的坑之一就是脚本无法执行尤其是从网上下载的编译脚本或者npm的构建脚本一跑就报无法加载文件 D:\Program Files (x86)\nodejs\npm.ps1因为在此系统上禁止运行脚本原因很直接PowerShell的执行策略默认禁止运行ps1脚本。这个设定本意是安全策略防止恶意脚本直接运行但开发时确实非常碍事。解决办法是在PowerShell里执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUserRemoteSigned表示本地脚本可以运行从网络下载的脚本必须带签名才能运行。这个设置只影响当前用户不会影响系统其他用户。工具链路径的问题更隐蔽。如果你把交叉编译器装在含空格或括号的路径下比如D:\Program Files (x86)\ARM\bin很多老构建脚本会把路径解析错因为空格会被当成参数分隔符。我的经验是所有开发工具能装根目录就装根目录不要让编译器目录带上空格。Linux下这个问题少一些但在Windows环境下路径带空格的坑会从各个意想不到的地方冒出来。6.2 编译报了“No such file or directory”但文件明明存在这个经典问题经常出现在交叉编译的产物传到开发板上运行时报错“./hello: No such file or directory”可是ls一看文件明明就在当前目录。这个问题的根源大部分是动态链接器缺失或者路径不正确。交叉编译出来的程序头部会记录动态链接器的路径。比如ARM硬浮点程序默认的链接器路径是/lib/ld-linux-armhf.so.3如果你的板子上的根文件系统里没有这个文件或者这个文件不存在内核加载可执行文件时就会直接返回“No such file or directory”。解决办法有两个一是检查根文件系统里是否有对应的动态链接器没有就补上二是用静态编译绕开动态库依赖编译的时候加-static参数。我做嵌入式产品原型时为了快速验证有时就会用静态编译反正程序不大体积无所谓减少很多环境问题。6.3 编译产物在开发板上运行时浮点指令崩溃交叉编译中最让人头疼的问题之一是程序在开发板上崩溃调试结果显示是执行浮点指令时出错。这个问题的根源就是之前反复强调的ABI不匹配特别是软浮点和硬浮点ABI的差异。比如用arm-linux-gnueabi-gcc软浮点编译的程序链接了硬浮点库运行时会尝试用通用寄存器传递浮点参数但库内部用VFP寄存器两边就对不上。崩溃是必然的。解决办法是在编译和链接时严格统一ABI标志。在CMake里可以用set(CMAKE_C_FLAGS -mfloat-abihard -mfpuvfpv4) set(CMAKE_CXX_FLAGS -mfloat-abihard -mfpuvfpv4)具体用哪个-mfpu参数取决于目标芯片的浮点单元。Cortex-A9一般用vfpv3Cortex-A7/A53一般可以用vfpv4或者neon。也可以用编译宏__ARM_PCS_VFP来判断当前编译配置是否启用了硬浮点。还需要注意的一点是在Linux下可以用readelf -A hello查看程序的属性段readelf -A hello输出的Tag_ABI_VFP_args也就是Tag_ABI_VFP_args: VFP registers段就说明了这个程序使用VFP寄存器传递参数也就是硬浮点ABI的标志和开发板上的工具链保持一致就对了。6.4 链接器报“skipping incompatible”以及找不到库的问题“skipping incompatible”是交叉编译最经典的一个错误出现频率极高。这个报错的大致意思是链接器找到了一个库文件但库的架构或格式与目标机不匹配所以跳过它。出现这个报错的情况通常有两种。你指定了-L/path/to/libs但/path/to/libs里的库文件是宿主机的x86版本这时候链接器就会跳过它们。另一情况是头文件找到了但库文件路径没配对链接器在默认路径里找不到目标架构的库。除了检查库架构还要重点检查CMake的CMAKE_FIND_ROOT_PATH和CMAKE_SYSROOT配置。我见过太多人在交叉编译时忘记设置CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY结果CMake在宿主机路径找到了x86库并传给链接器导致一连串诡异链接错误。把上一节给的那段CMake工具链文件里的三个MODE配置保留全就能避免大部分这类问题。如果你的项目用了pkg-config来查找依赖那还得配置PKG_CONFIG_LIBDIR环境变量指定到目标系统的.pc文件目录否则pkg-config找到的是宿主机里x86库的配置一切都白费。比如编译Qt项目要交叉编译Qt依赖时最好先设置export PKG_CONFIG_LIBDIR/opt/arm-sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig export PKG_CONFIG_SYSROOT_DIR/opt/arm-sysroot这样才能让pkg-config在目标系统的sysroot里找依赖的编译参数。6.5 版本匹配问题工具链、内核、glibc版本三者的兼容性交叉编译还有一个很多人忽视的大坑工具链版本与目标系统根文件系统的glibc版本不匹配。交叉编译器自带的头文件和标准C库默认是它发布时对应的版本。如果你用很新的交叉编译器编译程序在很老的板子上跑可能因为glibc符号版本过高而无法运行。经典的报错是运行时提示version GLIBC_2.34 not found (required by ./hello)这个报错说明程序依赖的glibc版本比板子实际安装的更高。解决办法是定制工具链时尽量选择与目标系统glibc版本相近的交叉编译器老的板子就找老版本的工具链不要一上来就用最新。最稳妥的做法是用和板子系统对应版本的官方工具链比如从芯片厂商的SDK里直接获取他们的配套工具链。还有一种办法是静态链接规避glibc版本问题但静态链接带来的体积膨胀和各种奇怪的NSSName Service Switch问题又会冒出来而且像DNS解析这类功能在静态链接下经常出毛病所以不是长久之计。7. 总结一下我的实操体会搞了这么多年嵌入式做了无数个交叉编译项目我最大的体会是交叉编译这个技术本身不复杂复杂的是它背后牵涉的那一整套目标系统的环境——工具链、ABI、动态链接器、库文件版本、内核配置任何一个环节不对产物在你电脑上是编出来了但到目标板上就是跑不了。所以每次搭建一个新的交叉编译环境我都会先跑一遍最小验证流程编译一个调用动态库的hello world程序用printf就算调用了libc的库了),然后在目标板上跑起来这个流程通过了才敢往项目里加复杂依赖。如果你一开始就直接编译一个包含几十个依赖的大项目出了问题根本没法定位是个别库不兼容还是工具链本身有坑。再分享一个小技巧。现在我的交叉编译环境全部用Docker容器化管理把工具链、目标系统的sysroot、依赖库全部打包成一个镜像。新加入项目的同事不需要在自己电脑上装一堆乱七八糟的东西直接docker pull镜像编译环境就是一致的。之前总有人问“为什么我的环境编译报错你的就没事”现在这个问题在项目里彻底消失了。如果你刚开始学交叉编译我建议你拿一块树莓派或者任何一个ARM开发板按上面的步骤亲手编译一个hello world再用QEMU在电脑上直接验证一下。这个流程跑通之后你对x86和ARM的关系、对交叉编译的理解就会完全不一样。 x86电脑如何编译ARM程序：交叉编译原理与实操全解析
“x86电脑能编译ARM程序”这个标题我第一眼看到的时候心里想的是这不是基础得不能再基础的常识吗后来发现问的人多了才意识到很多朋友刚接触嵌入式或者ARM开发时脑子里一直有个坎儿迈不过去——我用的明明是Intel的CPU写出来的程序怎么就能跑到手机、开发板那种ARM芯片上感觉像在北京做的川菜却端到了成都的餐桌上怎么想怎么不对劲。这个问题的答案其实藏在“编译”和“运行”的分离上。CPU架构只决定最终产物跑在什么机器上而编译这个动作本身只是在一个平台上执行一个翻译软件而已。这台“翻译软件”只要能在x86上跑起来它产出的目标文件是ARM格式的这一点都不矛盾。这就好比你用中文写了一份日文菜单菜单是用中文写的注释但菜品名称全是日文日本人拿到照样能点菜。编译器的源码、编译器本身、编译产物这三者的架构完全不要求一致这才是交叉编译能成立的根本前提。这篇内容我会从指令集和编译原理的角度把这件事彻底讲透再结合这些年做ARM Linux移植、嵌入式Linux应用开发、Qt交叉编译踩过的坑给出一套从零开始的交叉编译实操流程。适合刚接触嵌入式开发、做ARM平台移植、或者面试前想搞清楚编译原理底层逻辑的同学。1. 先厘清底层概念指令集、CPU架构与可执行文件的关系1.1 CPU架构就是“方言体系”指令集是底层词汇要理解为什么x86电脑能编译ARM程序先得把CPU的本质看清楚。CPU这东西本质上就是一个死板的执行器——它不认什么C语言、Java、Python只认自己的机器码。机器码是一串二进制每个二进制组合对应一个基本操作比如“把内存某个地址的数据搬到寄存器”“把两个寄存器里的数相加”“跳转到某个地址继续执行”。这一整套基本操作的二进制编码规则就叫指令集架构Instruction Set ArchitectureISA。x86和ARM的区别就在于这两套ISA完全不同。x86是复杂指令集CISC的典型代表指令长短不一、功能复杂一条指令能做的事情非常多历史上为了兼容性背了很重的包袱ARM是精简指令集RISC的典型代表指令定长ARM模式固定32位Thumb模式固定16位、规则整齐大多数指令只能做一件简单的事。更直观的差异是寄存器数量x86的通用寄存器数量少而ARM在标准模式下有一大排通用寄存器。这些底层的设计差异决定了同一段C代码在两种架构下会被编译成完全不同的机器指令序列。你写一句int sum a bx86编译出来可能是mov eax, [ebp-4]; add eax, [ebp-8; mov [ebp-12], eax]而ARM编译出来可能是ldr r0, [sp, #4]; ldr r1, [sp, #8]; add r0, r0, r1; str r0, [sp, #12]。看到没寄存器名都不同。直接把x86的二进制扔到ARM芯片上ARM会傻掉——它根本不知道eax是什么东西。1.2 可执行文件就是“一本写死的操作手册”我们平时说的编译就是把高级语言翻译成目标机器的操作手册。这个手册用的是哪种方言取决于你在编译时指定的目标架构而不是你当前用的电脑。这里有个关键认知可执行文件不是一个“程序本体”而是一份“指令清单数据清单”的打包文件。Windows的PE格式、Linux的ELF格式本质上都是容器里面装着目标架构能识别的机器指令。你用x86电脑编译ARM程序就是把指令清单用ARM的方言写好打包成ELF格式之后传到ARM板子上解包执行。编译那台电脑是什么架构和清单用什么方言写这两件事没有半毛钱关系。其实最典型的例子就是汇编器。你现在用的任何一款x86电脑上都装着能生成x86代码的编译器但你也可以通过添加目标说明让编译器生成ARM、RISC-V、MIPS等架构的代码。编译器不过是一个普通程序它怎么生成代码取决于它的内部实现里包含了几套“方言翻译规则”而不是它运行在什么CPU上。2. 交叉编译的核心逻辑为什么能在一个平台上为另一个平台产出程序2.1 编译四个阶段里到底哪一步涉及“架构”先朴素地过一遍编译流程预处理预处理器展开宏和头文件、编译把C/C翻译成汇编、汇编把汇编翻译成目标文件也就是机器码、链接把多个目标文件和库合并成最终可执行文件。注意看真正决定产物架构的是“汇编”这一步。编译器把C代码翻译成汇编文本时就已经按照目标架构的规则生成了对应的指令比如用ldr还是mov eax。随后汇编器把这些文本指令翻译成二进制机器码。所以编译器的“后端”决定了程序跑在什么架构上。这里就引入两个术语宿主机Host和目标机Target。宿主机是你当前用来干活的机器也就是x86电脑目标机是编译产物最终要运行的机器也就是ARM开发板。本地编译是Host与Target相同交叉编译是Host与Target不同。x86电脑编译ARM程序就是典型的交叉编译。2.2 打破直觉的一个事实编译器本身也是程序为什么很多人觉得x86不能编译ARM是因为潜意识里把“编译”想象成了CPU在“思考”怎么生成指令。其实编译器就是一个跑在x86上的普通程序它只是消耗CPU和内存资源。它内部挂载了ARM后端的代码生成逻辑执行到这步时会按照ARM的规则输出指令文本和二进制。它不要求CPU“懂ARM”只要求它自身能在x86上运行。打个比方一个译员他是中国人运行在x86上但他精通日语ARM指令集他能把中文小说C代码翻译成日文ARM机器码。翻译出来的书是日本人读的但这不影响译员自己生活在北京。编译器的角色就是那个译员x86架构是他生活的环境ARM汇编是他掌握的语言而编译一次就等于翻译一本新书。2.3 为什么交叉编译必须单独准备工具链因为编译器的“后端”通常是独立于“前端”的但标准的系统编译器在构建时只启用了一个目标后端。你要让x86电脑产生ARM代码就得用专门的交叉编译工具链比如arm-linux-gnueabihf-gcc。这套工具链是完整编译器的变体——它运行在x86上但默认目标架构是ARM。可能你会问为什么不直接用普通的gcc加个参数指定架构实际上gcc确实支持-march、-mabi这些选项但那只适用于同一个体系内的微调比如x86的-marchnative、-m32这种。真正跨架构编译时你需要的不仅是编译器本身还有人头文件、标准库的ARM版、链接器、汇编器这一整套东西在普通gcc里并不齐备。交叉工具链就是把这些打包好了的一套完整环境。3. 实操在x86电脑上搭建ARM交叉编译环境并编译出一个能跑的ARM程序3.1 工具链选型哪些交叉编译器最常见做ARM交叉编译第一个问题是用什么工具链。我见过很多新手在这里踩坑装了个工具链名字看着对结果编译出来的程序架构不对或者在板子上跑不起来。常见的几类工具链有这些arm-linux-gnueabihf-gcc最经典的ARM Linux交叉编译器。这是针对32位ARM架构、使用硬浮点hard-floatABI的工具链可以编译ARM Linux用户态程序生成的程序跑在装有Linux的ARM板子上。aarch64-linux-gnu-gcc64位ARMAArch64的交叉编译器编译出来的程序跑在ARMv8架构的64位Linux系统上比如树莓派的64位系统、大部分手机Linux发行版、一些服务器。arm-none-eabi-gcc不依赖操作系统的裸机交叉编译器。编译出来的程序不带Linux内核依赖直接烧录到单片机或者裸机ARM板上。这类工具链生成的程序没有操作系统概念适用场景是STM32这些裸机开发。ARM Compiler 5.06 / 6.x官方提供的商用编译器Keil MDK里默认集成的就是ARM Compiler 5.06。这个在嵌入式开发领域用得非常多后面我会单独说。我平时做ARM Linux应用层开发用得最多的是arm-linux-gnueabihf-gcc和aarch64-linux-gnu-gcc。如果是给树莓派64位系统编程序就用aarch64如果是给32位ARM开发板跑Linux就用arm-linux-gnueabihf。3.2 Linux环境下的交叉编译工具链安装在Ubuntu或者Debian系Linux上安装交叉工具链非常简单一条命令就搞定sudo apt update sudo apt install gcc-arm-linux-gnueabihf binutils-arm-linux-gnueabihf如果要编64位的就装sudo apt install gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu装好之后用arm-linux-gnueabihf-gcc --version验证能看到正常的版本信息就说明工具链装好了。这套工具链安装后会在/usr/bin/下生成一系列交叉工具包括编译器、汇编器、链接器、二进制工具arm-linux-gnueabihf-objdump、arm-linux-gnueabihf-readelf、arm-linux-gnueabihf-strip这些工具后面排查问题都要用到。有时候你还得装对应架构的标准库。很多发行版提供了跨架构的库包比如Debian系可以通过dpkg --add-architecture armhf来添加ARM架构软件源然后用apt install libc6-dev:armhf来安装ARM版本的标准库开发文件。这一步骤在做大型项目交叉编译时特别关键因为头文件和库文件都必须是对应目标架构的版本。3.3 Windows环境下的交叉编译工具链配置如果你的主力环境是Windows也完全可以做交叉编译。最靠谱的做法是用WSLWindows Subsystem for Linux安装一套Ubuntu然后在Ubuntu里按上面步骤安装交叉工具链。这个方案的好处是环境干净不污染Windows系统而且交叉编译本身对性能要求不高WSL2的I/O性能足够应付绝大部分项目。如果不想用WSL也可以直接下载独立的交叉编译工具链。ARM官方提供了GNU ARM Toolchain里面有Windows版本下载解压后把bin目录加入PATH就行。另外很多厂商也提供自己的交叉编译工具链比如在Windows上用Keil MDK做STM32开发本质上就是用了一套Windows环境下的ARM编译器。这里我想插一个特别的坑。Windows环境下经常有人把交叉编译器装好之后发现命令行根本跑不了报错提示是PowerShell禁止运行脚本。这个报错跟交叉编译本身无关但拦截率极高。错误信息长这样npm : 无法加载文件 D:\Program Files (x86)\nodejs\npm.ps1因为在此系统上禁止运行脚本这是因为PowerShell默认的执行策略是Restricted不允许执行任何.ps1脚本。解决办法就是临时放开当前用户的执行策略Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser之后重新打开终端就能执行npm和各类脚本了。这个坑在Windows环境做任何开发都会遇到第一次碰到记得先想到执行策略。3.4 最小实例编译一个ARM版Hello World工具链装好了我们来实战验证一下交叉编译是怎么回事。写一个最简单的C程序文件名为hello.c#include stdio.h int main(void) { printf(Hello, ARM!\n); return 0; }先用本地编译器编译一份x86版本gcc hello.c -o hello_x86 file hello_x86file命令会显示可执行文件的架构信息你看到的应该是类似“ELF 64-bit LSB pie executable, x86-64”的字样。然后咱们用交叉编译器来编译arm-linux-gnueabihf-gcc hello.c -o hello_arm file hello_arm这次file命令显示的结果就不一样了ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0看到“ARM, EABI5”这个字样就说明编译成功了——在你的x86电脑上产出的是一个ARM机器码的ELF文件。如果在本地试着直接运行./hello_arm会报“Exec format error”这个错误就直观地说明当前x86内核不认识ARM的机器码。3.5 怎么验证编译产物确实能在ARM上运行有一种快速验证的方法不用真板子可以用QEMU模拟ARM环境。Ubuntu下装个qemu-user就能直接跑ARM用户态程序sudo apt install qemu-user ./hello_arm如果一切正常你会看到终端打印Hello, ARM!。这里面qemu-user做的就是在x86系统上模拟ARM的CPU执行环境把ARM机器码一条条翻译成x86能执行的指令。这不是编译是模拟执行但是用来快速验证交叉编译产物是否可用特别方便。要验证产物里的动态库依赖可以用交叉编译器自带的readelf比如arm-linux-gnueabihf-readelf -d hello_arm它会列出这个ARM可执行文件依赖的动态库。如果交叉编译时动态库路径配置不对这里就能看出问题。4. 链接器、运行时库与ABI交叉编译里最阴险的坑都在这一层4.1 编译只是第一步ABI不一致照样跑不起来很多新手第一次成功编译出ARM程序后很兴奋结果传到开发板上一跑直接报“No such file or directory”。看着文件明明在怎么会找不到其实这个报错经常是动态链接器路径的问题。交叉编译出来的程序里写死了动态链接器的路径比如ARM硬浮点程序的动态链接器是/lib/ld-linux-armhf.so.3。如果你的板子上的根文件系统里没有这个文件或者用的是软浮点工具链路径对不上系统就报这个错。这里就涉及ABIApplication Binary Interface的概念。ABI是一套完整的二进制接口规范包括函数参数怎么传用寄存器还是栈、浮点参数怎么传用通用寄存器还是专用浮点寄存器VFP/NEON、结构体怎么对齐、系统调用怎么触发。两个程序就算CPU架构相同ABI不一致也没法互相兼容。ARM写Linux程序常见的ABI有软浮点soft-float和硬浮点hard-float。软浮点用通用寄存器传浮点参数硬浮点用VFP寄存器传。arm-linux-gnueabi-gcc生成的是软浮点程序arm-linux-gnueabihf-gcc生成的是硬浮点程序。如果你用软浮点工具链编译程序试图链接硬浮点的库链接器会直接报“selected processor does not supportvfpv3”这类的错误。所以选工具链时一定要明确目标系统的ABI否则调半天都不知道问题在哪。4.2 库文件也必须是对应架构的版本交叉编译时链接动态库-L指定的目录和-l指定的库名的格式这些库文件本身必须得是ARM架构的。如果你不小心链接了一个x86的.so文件链接器会报非常经典的错误skipping incompatible /usr/lib/libxxx.so when searching for -lxxx这个“skipping incompatible”翻译成人话就是我找到了一个库文件但它的格式跟目标机架构不匹配我跳过它。凡是看到这个报错先检查库的架构。用file命令查看库文件的架构信息file libxxx.so如果显示的是“x86-64”而不是“ARM”那就说明你的链接路径写错了找错库了。这也是交叉编译最折磨人的问题之一——库文件架构不匹配往往不会以直接报错的形式暴露而是要么skipping incompatible要么链接时根本找不到符号要么运行时提示动态库不存在。我自己处理这类问题时的经验是遇到链接错误第一反应不要只盯着库名先file一下库文件。如果项目是用CMake组织的还要检查CMAKE_SYSROOT和CMAKE_PREFIX_PATH的设置确保CMake优先在交叉编译的sysroot目标系统根目录下去找库而不会找到宿主机自带的x86库。4.3 静态库链接的隐藏炸弹动态库架构不匹配时会直接报错跳出来但静态库.a文件有个更阴险的情况。.a文件本质上是一个目标文件.o文件的归档包。链接时交叉编译器会把.a文件当做一个XX格式的目标文件来解析。如果你不小心给了它一个x86的.a文件编译器可能会直接把它当空归档文件处理慢慢查出问题。实际上GNU的链接器在解析.a的成员时也会做架构匹配检查。如果.a文件里的某个目标文件是x86的链接器还是能认出来。但有些老版本的链接器或某些特殊情况下报错信息可能不是特别明确让人以为是自己代码问题。所以只要是从第三方下载的静态库用之前务必跑一次arm-linux-gnueabihf-ar t libfoo.a arm-linux-gnueabihf-objdump -a libfoo.a看看里面目标文件的架构是不是ARM。这也是为什么厂商提供的SDK里通常有不同架构的库文件目录lib_armhf、lib_aarch64、lib_x86_64选错目录是家常便饭。4.4 大型项目交叉编译Qt、OpenCV的基本思路如果只是编译几个C文件交叉编译很快就能搞定。但实际工程中经常遇到Qt、OpenCV这类大型依赖库。这时候的核心思路是先用自己的交叉工具链把依赖库完整编译出ARM版本再在编译项目时指定使用这些ARM版本的头文件和库。以Qt为例你需要在x86电脑上用交叉工具链配置并编译Qt源码得到一套ARM版的Qt库。这个过程对新手来说确实繁琐涉及配置qmake.conf、设置交叉编译前缀、指定opengl或者eglfs这几个平台插件。我做过一次完整的根文件系统移植整个Qt库编译加安装大概花了两三个小时中间因为各种依赖报错反复调整配置。但编译完之后后续项目的交叉编译就变成了标准的“指定Qt路径调用交叉qmake”的流程。如果项目不是特别复杂也可以考虑用Docker构建一个包含交叉编译工具链和依赖库的镜像让整个编译环境可移植。这个方法在团队协作时尤其好用每个人拉同一个镜像编译环境完全一致很多“在我电脑上能编在你电脑上报错”的玄学问题直接消失。5. 常见交叉编译工具与IDE的交叉编译配置5.1 ARM Compiler 5.06为什么还这么流行热词里有不少人在搜arm compiler 5.06这让我很感慨。ARM Compiler 5.06 Update 7build 960是很多嵌入式工程师又爱又恨的东西。爱是因为它稳定兼容性好Keil MDK项目里的大量老代码都是用它编译的恨是因为它在新版本的Windows和IDE环境上经常出兼容性问题。ARM Compiler 5.06是32位的编译器安装目录通常在C:\Keil_v5\ARM\ARMCC\bin核心工具是armcc、armasm、armlink、fromelf。这些老工具的优势是对C99的支持非常好编译出来的代码体积小、稳定性高非常适合MCU级别Cortex-M系列的开发。很多人搜“arm compiler 5.06下载”通常是因为新装的Keil MDK默认带了AC6基于Clang但老工程必须用AC5编译不得不再补装。我当年在项目里就踩过这样一个坑工程用的芯片是Cortex-M4有大量低版本的老代码用AC6编译各种告警和错误换回AC5一口气编译通过。这就是为什么呼叫ARM Compiler 5.06的人越来越多——工程兼容性决定了工具链选型。5.2 在Eclipse、Visual Studio、CLion里配置交叉编译现在跨平台的IDE基本上都支持自定义工具链。以Eclipse为例在Project Properties - C/C Build - Settings里把gcc(编译器)和g(编译器)替换成交叉编译器的路径和名称再把头文件搜索路径加到交叉编译器对应的sysroot下。CLion和VSCode的标准做法是在CMake工具链中配置交叉编译器。CMake有个专门支持交叉编译的机制通过CMake工具链文件toolchain file来指定编译器、系统根目录和目标平台。一个最简的ARM toolchain文件写法如下set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc) set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g) set(CMAKE_SYSROOT /path/to/arm/sysroot) set(CMAKE_FIND_ROOT_PATH /path/to/arm/sysroot) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)这段配置的含义是告诉CMake目标系统是Linux on ARM编译器用交叉编译器头文件和库都在你指定的sysroot路径里找。最后三个MODE设置很关键PROGRAM设为NEVER是让CMake在宿主机上找程序比如编译器本身LIBRARY和INCLUDE设为ONLY是让CMake绝对不要在宿主机路径里找头文件和库这样就不会出现误链到x86库的问题。配置好后在IDE里选择这个CMake工具链点击构建就会自动调用交叉编译器。我推荐新手用CLion或VS CodeRemote之类的组合来做交叉编译因为它们的CMake支持更完善错误提示也直观。5.3 不用交叉编译的“懒人方案”如果不想在x86电脑上搭交叉编译环境还有几种替代方案。第一种是直接在ARM板子上编译——如果板子性能够用直接在板上装GCC再把源码拷过去编译。这种方法最保险但效率低而且很多资源紧张的嵌入式板子根本跑不动完整编译。第二种方案是在x86电脑上用QEMU启动一个ARM架构的虚拟机或用户态环境在模拟出来的ARM环境里编译。这种方式编译生成的产物和目标系统完全一致缺点是编译速度比纯交叉编译慢不少。第三种方案是使用Docker容器配合arm平台的镜像。从2022年开始新版Docker Desktop天然支持跨架构镜像运行能直接在x86电脑上跑ARM的Docker容器原理是用QEMU实现指令翻译然后在这个容器里编译代码。这种方法特别适合验证依赖多、系统库版本复杂的项目。要注意的是这类模拟方案虽然方便但它跟纯交叉编译是两码事。交叉编译生成ARM的代码但不会执行它而模拟方案是在x86电脑上实际运行ARM代码。前者速度更快后者兼容性检查更彻底两者各有适用场景。6. 交叉编译常见问题与排查实录6.1 Windows下脚本执行与工具链路径问题做交叉编译最常踩的坑之一就是脚本无法执行尤其是从网上下载的编译脚本或者npm的构建脚本一跑就报无法加载文件 D:\Program Files (x86)\nodejs\npm.ps1因为在此系统上禁止运行脚本原因很直接PowerShell的执行策略默认禁止运行ps1脚本。这个设定本意是安全策略防止恶意脚本直接运行但开发时确实非常碍事。解决办法是在PowerShell里执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUserRemoteSigned表示本地脚本可以运行从网络下载的脚本必须带签名才能运行。这个设置只影响当前用户不会影响系统其他用户。工具链路径的问题更隐蔽。如果你把交叉编译器装在含空格或括号的路径下比如D:\Program Files (x86)\ARM\bin很多老构建脚本会把路径解析错因为空格会被当成参数分隔符。我的经验是所有开发工具能装根目录就装根目录不要让编译器目录带上空格。Linux下这个问题少一些但在Windows环境下路径带空格的坑会从各个意想不到的地方冒出来。6.2 编译报了“No such file or directory”但文件明明存在这个经典问题经常出现在交叉编译的产物传到开发板上运行时报错“./hello: No such file or directory”可是ls一看文件明明就在当前目录。这个问题的根源大部分是动态链接器缺失或者路径不正确。交叉编译出来的程序头部会记录动态链接器的路径。比如ARM硬浮点程序默认的链接器路径是/lib/ld-linux-armhf.so.3如果你的板子上的根文件系统里没有这个文件或者这个文件不存在内核加载可执行文件时就会直接返回“No such file or directory”。解决办法有两个一是检查根文件系统里是否有对应的动态链接器没有就补上二是用静态编译绕开动态库依赖编译的时候加-static参数。我做嵌入式产品原型时为了快速验证有时就会用静态编译反正程序不大体积无所谓减少很多环境问题。6.3 编译产物在开发板上运行时浮点指令崩溃交叉编译中最让人头疼的问题之一是程序在开发板上崩溃调试结果显示是执行浮点指令时出错。这个问题的根源就是之前反复强调的ABI不匹配特别是软浮点和硬浮点ABI的差异。比如用arm-linux-gnueabi-gcc软浮点编译的程序链接了硬浮点库运行时会尝试用通用寄存器传递浮点参数但库内部用VFP寄存器两边就对不上。崩溃是必然的。解决办法是在编译和链接时严格统一ABI标志。在CMake里可以用set(CMAKE_C_FLAGS -mfloat-abihard -mfpuvfpv4) set(CMAKE_CXX_FLAGS -mfloat-abihard -mfpuvfpv4)具体用哪个-mfpu参数取决于目标芯片的浮点单元。Cortex-A9一般用vfpv3Cortex-A7/A53一般可以用vfpv4或者neon。也可以用编译宏__ARM_PCS_VFP来判断当前编译配置是否启用了硬浮点。还需要注意的一点是在Linux下可以用readelf -A hello查看程序的属性段readelf -A hello输出的Tag_ABI_VFP_args也就是Tag_ABI_VFP_args: VFP registers段就说明了这个程序使用VFP寄存器传递参数也就是硬浮点ABI的标志和开发板上的工具链保持一致就对了。6.4 链接器报“skipping incompatible”以及找不到库的问题“skipping incompatible”是交叉编译最经典的一个错误出现频率极高。这个报错的大致意思是链接器找到了一个库文件但库的架构或格式与目标机不匹配所以跳过它。出现这个报错的情况通常有两种。你指定了-L/path/to/libs但/path/to/libs里的库文件是宿主机的x86版本这时候链接器就会跳过它们。另一情况是头文件找到了但库文件路径没配对链接器在默认路径里找不到目标架构的库。除了检查库架构还要重点检查CMake的CMAKE_FIND_ROOT_PATH和CMAKE_SYSROOT配置。我见过太多人在交叉编译时忘记设置CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY结果CMake在宿主机路径找到了x86库并传给链接器导致一连串诡异链接错误。把上一节给的那段CMake工具链文件里的三个MODE配置保留全就能避免大部分这类问题。如果你的项目用了pkg-config来查找依赖那还得配置PKG_CONFIG_LIBDIR环境变量指定到目标系统的.pc文件目录否则pkg-config找到的是宿主机里x86库的配置一切都白费。比如编译Qt项目要交叉编译Qt依赖时最好先设置export PKG_CONFIG_LIBDIR/opt/arm-sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig export PKG_CONFIG_SYSROOT_DIR/opt/arm-sysroot这样才能让pkg-config在目标系统的sysroot里找依赖的编译参数。6.5 版本匹配问题工具链、内核、glibc版本三者的兼容性交叉编译还有一个很多人忽视的大坑工具链版本与目标系统根文件系统的glibc版本不匹配。交叉编译器自带的头文件和标准C库默认是它发布时对应的版本。如果你用很新的交叉编译器编译程序在很老的板子上跑可能因为glibc符号版本过高而无法运行。经典的报错是运行时提示version GLIBC_2.34 not found (required by ./hello)这个报错说明程序依赖的glibc版本比板子实际安装的更高。解决办法是定制工具链时尽量选择与目标系统glibc版本相近的交叉编译器老的板子就找老版本的工具链不要一上来就用最新。最稳妥的做法是用和板子系统对应版本的官方工具链比如从芯片厂商的SDK里直接获取他们的配套工具链。还有一种办法是静态链接规避glibc版本问题但静态链接带来的体积膨胀和各种奇怪的NSSName Service Switch问题又会冒出来而且像DNS解析这类功能在静态链接下经常出毛病所以不是长久之计。7. 总结一下我的实操体会搞了这么多年嵌入式做了无数个交叉编译项目我最大的体会是交叉编译这个技术本身不复杂复杂的是它背后牵涉的那一整套目标系统的环境——工具链、ABI、动态链接器、库文件版本、内核配置任何一个环节不对产物在你电脑上是编出来了但到目标板上就是跑不了。所以每次搭建一个新的交叉编译环境我都会先跑一遍最小验证流程编译一个调用动态库的hello world程序用printf就算调用了libc的库了),然后在目标板上跑起来这个流程通过了才敢往项目里加复杂依赖。如果你一开始就直接编译一个包含几十个依赖的大项目出了问题根本没法定位是个别库不兼容还是工具链本身有坑。再分享一个小技巧。现在我的交叉编译环境全部用Docker容器化管理把工具链、目标系统的sysroot、依赖库全部打包成一个镜像。新加入项目的同事不需要在自己电脑上装一堆乱七八糟的东西直接docker pull镜像编译环境就是一致的。之前总有人问“为什么我的环境编译报错你的就没事”现在这个问题在项目里彻底消失了。如果你刚开始学交叉编译我建议你拿一块树莓派或者任何一个ARM开发板按上面的步骤亲手编译一个hello world再用QEMU在电脑上直接验证一下。这个流程跑通之后你对x86和ARM的关系、对交叉编译的理解就会完全不一样。