直接把gcc装到板子上编译听起来没问题但真正做过嵌入式Linux开发的人都知道这条路在项目稍微大一点之后就走不通了。交叉编译器Cross Compiler解决的就是这件事在一台x86的Linux开发机上编译出能跑在ARM、MIPS、RISC-V这些目标平台上的可执行文件。无论你是刚拿到一块开发板想跑个Hello World还是后面要做Linux驱动、Qt界面、嵌入式Linux项目交叉编译器都是绕不开的第一道门槛。这篇文章我会把从工具链选型、安装、环境配置到实际排障的完整链路写清楚并按我的实操经验把最容易踩的坑放在一起讲。1. 为什么你的Linux开发机上必须有一副交叉工具链1.1 交叉编译到底解决什么问题先明确一个基本概念程序编译出来的二进制文件和CPU架构是强绑定的。x86编译出来的程序放到ARM板子上根本跑不了反过来也一样。在不了解这一点之前很多新人会想当然地认为板子上有Linux我把gcc装上不就行了 这个思路在小程序上确实可行但等你试图在ARM板子上编译一个Linux内核或者Qt5就会明白什么叫度秒如年——板子CPU主频低、内存小一个内核编译几小时是家常便饭。交叉编译的思路就是在性能强劲的PC上用一套专门生成目标平台机器码的编译器编译出能在板子上直接运行的程序。这套编译器就是标题里说的交叉编译器。它生成的不是开发机自己能运行的程序而是目标板子能识别的二进制。编译速度、磁盘占用、团队协作效率都远优于在板子上现场编。1.2 host与target以及一副完整工具链包含什么嵌入式开发里有两个常用术语host是运行编译器的主机也就是你的PCtarget是运行生成程序的目标机也就是开发板。两者架构不同所以称为交叉编译。如果两者架构相同那就是本地编译比如你在Linux x86机器上装gcc编出来的程序还在x86机器上跑。很多人以为交叉编译器就是arm-linux-gnueabihf-gcc这一个命令其实不对。一副完整的交叉工具链至少包含交叉编译器arm-linux-gnueabihf-gcc汇编器arm-linux-gnueabihf-as链接器arm-linux-gnueabihf-ldC运行库及头文件arm-linux-gnueabihf对应的libc和include调试器arm-linux-gnueabihf-gdb辅助工具arm-linux-gnueabihf-objdump、readelf、strip、nm、size等可以把它理解成一条完整的生产线而不是一把螺丝刀。普通gcc和交叉gcc之间的差别不只是名字带了个前缀而是整套工具链都针对目标平台做了重新配置和编译。你平时在Linux下写的Makefile一旦把CC变量从gcc换成arm-linux-gnueabihf-gcc后面链接、汇编、strip全都得跟上否则编到一半就会断。1.3 有没有必要先在PC上编译再传板子拿一块树莓派或者全志、瑞芯微的板子来说如果你只是临时改个测试脚本直接在板子上跑Python、解释执行那确实不需要交叉编译。但一旦涉及C/C程序、内核模块、驱动、Qt应用绝大多数项目组都会选择交叉编译。理由很朴素第一PC编译速度快几分钟能完成的事何必让板子跑半小时第二板子的存储和内存都很有限装完gcc、make、libc-dev这些工具链之后空间被占掉一大截第三正式开发要保证所有人用同一套编译器版本在板子上各自为战很容易出现我这能编过你那编不过的情况。如果你目前还没有Linux环境建议先在虚拟机里装一个Ubuntu LTS版本后面我给的命令基本都能照抄。很多嵌入式初学者就是靠虚拟机里的Linux完成交叉编译再把产物传到物理板子上的这条路完全走得通。2. 选型先查清板子架构再决定装哪套编译器2.1 拿到板子先执行这两条命令安装交叉编译器之前第一件事不是下载工具链而是搞清楚目标板子的CPU架构。在开发板的系统终端里执行uname -m cat /proc/cpuinfouname -m会直接告诉你机器架构。如果你的板子输出aarch64那就是64位ARM对应工具链前缀是aarch64-linux-gnu-。如果输出armv7l、armv6l这类就是32位ARM对应arm-linux-gnueabihf-或者老旧的arm-linux-gnueabi-。cat /proc/cpuinfo则能看出更细的CPU特性。重点看Features这一行有没有vfp、neon、asimd等字眼。如果板子支持这些优先选带hf的工具链也就是硬浮点版本。如果是一块很老的ARM9板子比如S3C2440这种不带FPU就得选软浮点工具链。2.2 硬浮点和软浮点的区别硬浮点hard-float和软浮点soft-float/softfp是32位ARM交叉编译里绕不开的选择题。硬浮点工具链编译出的程序直接使用CPU的浮点运算单元FPU指令浮点计算性能好软浮点工具链则用普通的整数指令模拟浮点运算兼容性高适合没有FPU的老芯片。判断方法我已经给了就是看/proc/cpuinfo的Features。只要是现代的Cortex-A系列处理器基本都带VFP或NEON直接选arm-linux-gnueabihf-就行。但要注意一旦选了gnueabihf工具链编译出的可执行文件对动态库的依赖也必须是硬浮点的如果你的板子根文件系统里的libc等库是软浮点编译的程序就跑不起来。这也是为什么我建议初学者优先考虑用Buildroot或Yocto构建一套完整系统而不是随手拿一个工具链去编。2.3 三套主流工具链方案的取舍我把常见的工具链获取方式整理成一张表方便对照自己的场景选择方案优点缺点适合场景apt安装gcc-arm-linux-gnueabihf一条命令装好依赖自动处理版本随发行版相对偏旧sysroot不完整初学者、快速验证、通用场景官方ARM GNU工具链 / Linaro版本新bin目录配好即可用需要手动配置PATH体积较大项目正式开发、需要高版本GCC特性Buildroot / crosstool-NG自编译工具链与根文件系统完全匹配编译耗时长配置门槛高定制系统、特殊C库、量产方案如果你的板子系统是Buildroot或Yocto构建出来的最稳妥的办法是用构建系统自带的工具链或者在Buildroot里勾选Build a toolchain选项让它在编译系统的时候顺便生成一副匹配的工具链。这样能最大程度避免后面出现glibc版本不匹配的问题。另外提醒一个细节目标板上的C库不一定是glibc。有些精简系统用musl或uclibc这时你用glibc工具链编出来的程序拷到板子上大概率跑不了。拿到板子后在板子上执行ls -l /lib/ld-linux*或者ls -l /lib/libc.so*能看到ld-linux和libc的存在基本就是glibc系统可以放心用标准工具链。3. 安装全流程apt一条龙与Linaro手动部署3.1 方法一apt一条龙安装Ubuntu和Debian系Linux中最省事的安装方式是直接用apt以32位ARM为例sudo apt update sudo apt install gcc-arm-linux-gnueabihf如果你的板子是64位ARM安装的是另一个包sudo apt install gcc-aarch64-linux-gnuapt会自动把binutils、libc开发库等依赖一起装上省去了手动配环境的时间。装完之后可以验证一下arm-linux-gnueabihf-gcc -v正常会输出版本信息包括gcc版本、configure参数等。如果你安装了64位的则执行aarch64-linux-gnu-gcc -v。此时你在/usr/bin目录下会看到一堆arm-linux-gnueabihf-前缀的命令这些就是全套工具链家族。apt方式的缺点是版本一般不会太新而且编译器默认的sysroot是/usr/arm-linux-gnueabihf里面虽然带了基本的头文件和库但如果你需要完整的、和板子系统一致的全套库单靠apt装出来的工具链是不够的。这也解释了为什么很多人用apt装完工具链后编译一些系统级程序时会遇到缺库的报错。3.2 方法二手动部署Linaro工具链需要更新版本或更完整sysroot的场景我建议直接下载Linaro发布的预编译工具链包。目前Linaro发布的工具链可以在它的releases页面找到选择你需要的版本和解压格式例如wget https://releases.linaro.org/components/toolchain/binaries/7.5-2019.12/arm-linux-gnueabihf/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf.tar.xz sudo mkdir -p /opt/toolchains sudo tar -xJf gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf.tar.xz -C /opt/toolchains解压出来之后工具链的bin目录就是我们需要加进PATH的地方。注意的坑是一定不要在Windows下用压缩软件解压再拷贝到Linux因为权限位会丢失解压出来的可执行文件可能没有执行权限。直接在Linux下用tar解压是最稳妥的。3.3 配置PATH临时生效与永久生效手动部署的工具链bin目录默认不在PATH里所以你需要把路径加进去。只在当前终端临时生效的做法export PATH/opt/toolchains/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin:$PATH这个方法关掉终端就失效。想永久生效可以追加到当前用户的~/.bashrcecho export PATH/opt/toolchains/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin:$PATH ~/.bashrc source ~/.bashrc如果整个开发机多人共用也可以写到/etc/profile.d/下例如新建一个/etc/profile.d/cross-env.sh文件内容就是上面那行export所有用户登录时都会加载。3.4 多套工具链共存的管理技巧实际项目做久了开发机上往往不止一套工具链32位产品一套、64位产品一套、某个老内核还要配套对应版本的GCC。我个人的习惯是全部放在/opt/toolchains目录下用版本号命名然后在每个项目根目录放一个env.sh#!/bin/bash export CROSS_COMPILEarm-linux-gnueabihf- export CC${CROSS_COMPILE}gcc export PATH/opt/toolchains/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin:$PATH编译前执行source env.sh当前终端就切到对应工具链。这样换项目时互不干扰也不会因为全局PATH里有多个同名命令导致用错版本。这个习惯帮我省下了很多莫名其妙的问题。4. 第一个Hello World从编译、验收到上板运行4.1 写一个测试程序并交叉编译装好工具链之后先用一个最简单的程序把整个链路跑通。新建hello.c#include stdio.h int main(void) { printf(hello, cross compile!\n); return 0; }交叉编译arm-linux-gnueabihf-gcc -o hello hello.c如果这一步报command not found说明PATH没有配好回头检查第3章。如果报头文件找不到说明你的工具链sysroot有问题我会在第5章细说。4.2 用file命令验证产物架构编译成功不意味着万事大吉我在项目里见过太多人编完就传板子结果跑不了。拿到产物后第一步先用file命令看文件格式file hello正常的ARM 32位交叉编译产物输出类似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, not stripped作为对比本机gcc编译出来的产物是ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked ...如果你交叉编译得到的是x86-64说明实际调用的还是本机gcc。常见的元凶是Makefile里写死了gcc而不是$(CC)或者没有用env.sh里的CC变量。这个错误很隐蔽新手很容易被搞懵。4.3 传到板子并运行传文件的方法很多开发板有网络的话首选scp板子和开发机在同一局域网时scp hello root192.168.1.100:/root/如果开发板没有网口U盘拷贝也行但要注意文件系统格式FAT32能直接挂载exFAT有时候要装额外驱动。传过去之后在板子上chmod x hello ./hello如果一切正常你会看到hello, cross compile!到这里你的交叉编译器安装和目标板运行链路就算打通了。4.4 静态编译什么时候用在板子上跑动态链接的程序时系统必须要有对应的动态库。如果板子文件系统非常精简比如自行裁剪过的根文件系统缺了libc.so.6动态链接的hello就跑不了。这时候可以改成静态编译arm-linux-gnueabihf-gcc -static -o hello_static hello.c静态编译会把libc直接打进可执行文件里不依赖板子上的动态库。对比一下可以看到动态版可能只有8KB左右静态版一般700KB起步体积差很远。这不是说静态编译一定好而是明确一个原则成品系统用动态链接更节省空间、方便库升级调试阶段或精简系统上静态编译能省去一堆依赖问题。另外如果你在PC上直接执行这个ARM程序会看到cannot execute binary file: Exec format error。这是正常现象因为x86的内核不认识ARM的可执行文件格式。出现这个错误反而说明你的产物确实是ARM架构拿着这个产物去板子上跑就对了。5. 新手必踩四连坑command not found、sysroot与GLIBC版本5.1 坑一明明装了却提示command not found现象很直白在终端里执行arm-linux-gnueabihf-gcc -v系统回一句command not found。很多人第一反应是没装好于是又重新装了一遍但仍然报错。排查链路应该这样走先确认编译器到底装没装dpkg -l | grep arm-linux-gnueabihf或者手动解压场景下ls -l /opt/toolchains/.../bin/arm-linux-gnueabihf-gcc查看PATH里有没有工具链路径echo $PATH用apt装的工具链命令在/usr/bin下这个目录默认在PATH里基本不会出现找不到。用手动解压的工具链多半是PATH没配好或者没source。如果你把工具链放在/opt下但echo $PATH里看不到/opt/toolchains/.../bin那就别怪系统找不到。检查可执行权限ls -l /opt/toolchains/.../bin/arm-linux-gnueabihf-gcc如果在Windows下解压再拷回Linux文件权限可能变成644没有x权限执行时也会报command not found或者Permission denied。直接chmod x就能解决。5.2 坑二sysroot与头文件/库找不到现象是编译时出现fatal error: stdio.h: No such file or directory或者链接时cannot find -lpthread出现这个问题的本质是交叉编译器默认不会去你的Linux开发机上找/usr/include和/usr/lib。它有自己的sysroot目录可以理解成目标板根文件系统的一个快照。在这个快照里编译器才能找到与目标架构匹配的stdio.h、libc.so、ld-linux等文件。apt安装的交叉编译器sysroot通常在/usr/arm-linux-gnueabihf里面有自己的include和lib目录。手动解压的Linaro工具链sysroot在工具链目录内的arm-linux-gnueabihf/libc下。想确认当前工具链的sysroot可以执行arm-linux-gnueabihf-gcc -print-sysroot如果编译时确实需要额外的第三方头文件或库就用-I和-L指定路径arm-linux-gnueabihf-gcc -I/opt/armlib/include -L/opt/armlib/lib -o app app.c -lfoo这里特别强调绝对不要拿x86的.a或.so文件给ARM的交叉编译器去链接。架构不对链进去必炸运行时各种非法指令。跨架构的库必须用交叉编译器重新编译。5.3 坑三板子上报No such file or directory但文件明明存在这是交叉编译里最迷惑人的一个报错我几乎每隔一段时间就会看到有人问。现象是文件已经scp到板子上ls能看到hello执行./hello却提示-bash: ./hello: No such file or directory注意这里报的不是Permission denied也不是File not found而是No such file or directory。很多人第一反应是换行符或文件损坏问题其实都不是。真正的原因是系统找不到能加载这个ELF文件的动态链接器。一个动态链接的ARM可执行文件内部有一个PT_INTERP段记录了动态链接器的路径。查看方式readelf -l hello | grep interpreter输出通常为[Requesting program interpreter: /lib/ld-linux-armhf.so.3]如果板子的/lib目录下没有ld-linux-armhf.so.3这个文件内核加载程序时就找不到解释器于是返回No such file or directory。它真正想说的是文件中指定的解释器路径不存在而不是文件本身不存在。排查和解决的办法有几个板子上确认ls -l /lib/ld-linux-armhf.so.3如果确实没有最简单的办法是改用静态编译-static产物不需要动态链接器。如果必须动态链接可以尝试把交叉工具链sysroot里对应的ld-linux-armhf.so.3、libc.so.6、libm.so.6拷贝到板子的/lib目录下。但拷贝库容易引发glibc版本不一致的新问题除非你很清楚自己在做什么否则不太推荐新手走这条路。最根本的解决办法是保证工具链的sysroot和目标板的根文件系统一致。很多人用Buildroot/Yocto构建系统工具链和库天然同步就不会出现这种问题。5.4 坑四GLIBC_2.27 not found还有一个高频报错在板子上运行时出现./hello: /lib/arm-linux-gnueabihf/libc.so.6: version GLIBC_2.27 not found原因是编译时用的工具链自带glibc版本比较新编译出的程序引用了新版本的符号而板子上的glibc比较老没有这些符号。这就像你在高版本系统上编出来的程序拿到老系统上跑非常容易出现兼容性问题。排查时先在PC上确认工具链的glibc版本strings /usr/arm-linux-gnueabihf/lib/libc.so.6 | grep GLIBC_再看板子的strings /lib/arm-linux-gnueabihf/libc.so.6 | grep GLIBC_两边对比就知道差距。解决办法有三个方向一是换一个和板子glibc版本匹配的旧工具链二是升级板子文件系统的glibc这通常意味着重建根文件系统三是尽量在构建目标系统时就确定工具链版本用Buildroot/Yocto这类工具从一开始就对齐版本。这四个坑基本覆盖了交叉编译新手90%的报错原因。别同时踩完这四个你的项目至少能少熬一周的夜。6. 装完只是开始内核模块和Qt项目的交叉编译实践6.1 交叉编译Linux内核模块的Makefile配置很多热搜里提到内核动态加载file_operations拦截read write这其实就是典型的Linux驱动模块开发。写一个内核模块实现自己的file_operations结构体然后在板子上insmod加载dmesg看输出。这类开发必须用目标板同架构的内核源码加交叉编译器。内核模块的Makefile长这样obj-m : hello_driver.o KERNELDIR : /home/user/linux-5.10 PWD : $(shell pwd) all: make -C $(KERNELDIR) M$(PWD) ARCHarm CROSS_COMPILEarm-linux-gnueabihf- modules clean: make -C $(KERNELDIR) M$(PWD) ARCHarm CROSS_COMPILEarm-linux-gnueabihf- clean这里有个关键点KERNELDIR指向的内核源码必须是和目标板同架构、同版本的内核源码。交叉编译器通过CROSS_COMPILEarm-linux-gnueabihf-告诉内核构建系统用哪一套工具链而ARCHarm则指定了目标架构。编译完成后生成的hello_driver.ko传到板子上用insmod加载lsmod确认再rmmod卸载。一个基本的驱动开发流程就跑通了。交叉编译器的价值在这里体现得很明显驱动模块不能直接在PC上编译因为它依赖内核源码树而且编译出的.ko文件必须和目标板内核模块版本一致。没有交叉工具链你连.ko都编不出来。6.2 Qt ARM开发中工具链的联动热搜词里有qt5.5.10 arm linux开发这是很多嵌入式团队的日常。要在ARM板子上跑Qt程序需要的不只是交叉编译器还需要交叉编译tslib触摸屏校准库再交叉编译Qt5源码通过-xplatform linux-arm-gnueabihf-g指定qmake的交叉编译平台。整个流程大致是先交叉编译tslib生成ARM架构下的libts库配置Qt源码指定交叉工具链路径和tslib安装路径编译安装Qt到指定前缀目录用交叉工具链编译你的Qt应用把Qt运行库、tslib库和应用一起部署到板子上。这里面最底层的依赖仍然是交叉编译器。Qt的qmake只是把编译、链接命令封装了一层最终调用GCC的还是arm-linux-gnueabihf-gcc。如果工具链sysroot不完整、glibc版本不匹配Qt的configure阶段就可能报错。6.3 一个完整的工具链验证清单装完交叉编译器我强烈建议按下面这份清单过一遍省得后面项目里反复返工arm-linux-gnueabihf-gcc -v能正确输出版本echo $PATH能看到工具链bin目录file hello输出的架构是ARM不是x86-64readelf -l hello | grep interpreter能看到/lib/ld-linux-armhf.so.3在开发板上实际运行一次输出正常尝试链接一个第三方库确认-l参数能找到目标平台的库文件。这六点全过一遍你这套交叉编译环境才算真正可用。我自己这几年的习惯是把每个板子的工具链连同它的sysroot一起归档而不是随手从网上下个工具链就编。因为很多编译过了但板子跑不起来的问题追根究底都是工具链和根文件系统不匹配。交叉编译器的安装只是第一步真正考验人的是如何让工具链、库、板子系统三者之间保持一致。把这套思路理顺了后面无论是驱动开发还是Qt界面项目都会顺畅很多。
