搞嵌入式开发的基本都绕不开交叉编译。简单说你的开发机是x86架构目标板子却是ARM架构你不能指望在PC上直接编译出ARM能跑的程序因为两者指令集不一样。这时候就需要一套交叉编译工具链在x86主机上编译出ARM目标板上可执行的程序。Linaro工具链就是目前ARM嵌入式开发里非常主流的一套方案这篇文章我就从零开始把Linaro交叉编译工具链的安装与配置完整走一遍重点讲清楚环境变量设置里那些容易让人抓狂的坑。这篇文章适合什么人看刚接触嵌入式Linux、第一次要给ARM开发板比如全志、瑞芯微、树莓派、香橙派这类板子编译程序或内核的开发者或者被各种工具链版本、环境变量搞到头大的朋友。我会把下载、解压、配置、验证、编译实测的完整过程都贴出来也会把我在实际项目中踩过的坑、排查思路一并分享尽量让你照着做就能一次跑通。1. 交叉编译场景与Linaro工具链选型1.1 交叉编译到底在解决什么问题很多刚入门的同学会有个疑问我在Ubuntu里装个gcc直接编译不就行了吗为什么非要搞交叉编译工具链这里的关键在于“目标平台不一致”。普通的gcc编译出来的可执行文件是给当前这台x86机器用的。但ARM开发板上的CPU架构、字节序、浮点处理方式、系统库接口都和x86不一样。你用系统自带的gcc去编译一个hello程序编译是能过的但把这个文件拷到ARM板子上运行系统会直接告诉你“cannot execute binary file: Exec format error”因为二进制格式根本不匹配。交叉编译工具链的本质就是一套“运行在A架构上、但生成B架构代码”的编译工具集合。Linaro提供的工具链里包含了交叉编译器gcc、汇编器as、链接器ld、C库和头文件等你在这边编译编译出来的东西直接扔到开发板上跑不需要在板子上装庞大的编译环境。这对于开发环境部署来说相当省事尤其板子存储小、性能弱的时候交叉编译几乎是唯一合理选择。1.2 为什么选Linaro而不是其他工具链ARM嵌入式开发里常用的工具链其实有好几种Linaro GCC、ARM官方提供的arm-none-eabi-gcc主要用于裸机/RTT这类无操作系统场景、Buildroot自带工具链、以及SoC厂商魔改的交叉编译器。我的选择逻辑是这样的如果你的程序运行在Linux系统上跑在Cortex-A系列的处理器上Linaro工具链往往是最省心的。它基于GCC主线维护由Linaro组织专门针对ARM架构做优化性能不错更新也比较及时。而且它的二进制包是预编译好的不用自己从源码折腾一整天下载解压就能用这对快速搭建开发环境来说太重要了。另外Linaro的命名和目录组织非常清晰一套工具链里编译器、库、头文件都齐了写makefile时一套prefix搞定不像某些厂商工具链还要额外配置sysroot路径。所以我在几个项目里对比过之后Linaro几乎成了我的默认选择。1.3 看懂工具链文件名别再下错版本Linaro工具链的文件名包含大量信息很多人第一次看到就懵了。举个例子我常用的这个gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf.tar.xz拆开来看就几部分gcc版本是7.5.0发布批次是2019.12主机平台是x86_64目标平台是arm-linux-gnueabihf。最后这段“arm-linux-gnueabihf”是整个文件名的灵魂它告诉你了三件事——目标架构是ARM运行在Linux系统上使用的是gnueabihf这个嵌入式ABI即ARM硬浮点Hard-Float。这里有个重要区分如果你要编64位的ARM程序需要选择名字里带“aarch64-linux-gnu”的版本比如aarch64-linux-gnu-gcc如果你是给32位ARM目标编译就选arm-linux-gnueabihf。如果你的目标平台是古老的ARM926这类不带硬件浮点单元的CPU又需要选择gnueabi的软浮点版本。搞错这个编译过程中会出现大量莫名其妙的链接错误。注意我见过有人拿aarch64工具链去编arm-linux-gnueabihf的程序结果一路报错“cannot find crt1.o”。这就是sysroot里的库和编译器架构不匹配导致的属于最典型的选型错误。2. 安装前准备与下载2.1 确认目标架构和主机架构动手之前先用两个简单的命令确认环境。主机架构用下面这个看uname -m如果是x86_64说明你的开发机是64位x86架构下载x86_64版本的Linaro工具链没问题。目标板子的架构怎么看在板子的Linux终端里同样执行uname -m或者根据SoC型号来确定。比如全志H3/H5、瑞芯微RK3328这类是32位Cortex-A7的一般用arm-linux-gnueabihf而RK3399、全志H6、树莓派4B这些64位平台通常就需要aarch64-linux-gnu工具链。注意即使是64位SoC内核也可能跑在32位模式或者你只想编译32位程序那就选arm-linux-gnueabihf。这个要结合目标系统实际情况定不能想当然。2.2 下载工具链的正确姿势Linaro工具链的官方下载地址在releases.linaro.org按年份和组件版本分类存放。为了避免有人找不到具体目录我这里直接给出一个相对稳定的获取思路到Linaro官网的Toolchain Binaries页面选择对应的版本和架构下载。如果你的网络访问官方地址速度不理想也可以找国内的开源镜像站比如部分高校镜像或阿里云镜像里有时会同步Linaro Release文件搜索“gcc-linaro-7.5.0 x86_64 arm-linux-gnueabihf 镜像”通常能找到。下载时优先选.tar.xz后缀的包压缩率高、体积小解压速度也快。以我习惯的版本为例在终端里用wget直接拉取mkdir -p ~/toolchains cd ~/toolchains wget https://releases.linaro.org/components/toolchain/binaries/latest-7/arm-linux-gnueabihf/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf.tar.xz这个路径里的“latest-7”表示GCC 7系列的最新批次。版本号选择上没必要一味追求最新稳定、兼容性好才是关键。7.5.0算是一个比较成熟的版本我用了很久没出过大问题。2.3 路径规划与文件校验很多初学者喜欢把工具链解压到根目录或系统目录比如/opt。这没毛病但要注意权限问题——如果你不用root操作解压到/opt之后写不进去后面会遇到一堆权限报错。我更推荐把工具链放在用户目录的toolchains文件夹下比如/home/你的用户名/toolchains/这样的好处是不需要sudo权限、不容易误删系统文件、重装系统前直接打包这个目录就能迁移。等到你确认这套工具链稳定可用、以后一定要全系统共享再考虑挪到/opt都不迟。下载完成后建议先做一下文件校验防止下载不完整导致解压失败。Linaro的发布页面通常有对应的.sha或.md5校验文件。用sha256sum命令就能比对sha256sum gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf.tar.xz把输出值和官方页面给出的校验值对比一致再继续。这个步骤虽然多花十秒钟但能避免后面解压出“archive header is corrupt”这类让人无语的问题。3. 解压安装与环境变量配置全流程3.1 解压并检查目录结构下载完的tar.xz包解压命令如下cd ~/toolchains tar -xJf gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf.tar.xz解压完成后进入目录看看结构cd gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf ls你会看到bin、include、lib、libexec、share等目录。其中bin目录放的是所有可执行工具包括arm-linux-gnueabihf-gcc、arm-linux-gnueabihf-g、arm-linux-gnueabihf-ld、arm-linux-gnueabihf-strip等。此时你可以直接尝试调用编译器./bin/arm-linux-gnueabihf-gcc --version如果这里能正常输出版本信息说明工具链本身没问题接下来要做的就是把它加入环境变量让系统任何位置都能直接调用。3.2 配置环境变量的完整操作环境变量配置是整个安装过程中最容易被搞砸的环节。我的做法是编辑用户目录下的.bashrc文件把配置追加到文件末尾vim ~/.bashrc在文件末尾添加以下内容export PATH$PATH:/home/你的用户名/toolchains/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin export CROSS_COMPILEarm-linux-gnueabihf- export CC${CROSS_COMPILE}gcc第一行是编译器的搜索路径第二行定义交叉编译前缀这个在编译内核、U-Boot时特别有用make工具会根据这个变量自动拼接出完整的编译器名第三行是把CC变量直接指向交叉编译器防止有些makefile只用CC时还调用系统gcc。保存后执行source ~/.bashrc让配置立即生效。这一步特别要注意很多同学改完.bashrc忘了source或者干脆没改对文件导致终端还是找不到命令。注意如果你用的不是bash而是zsh那要改的是~/.zshrc改了.bashrc是不会自动加载的。这一点在我用zsh的机器上踩过坑特此提一句。3.3 验证与版本信息确认配置好环境变量之后验证是否成功最简单的方法就是开一个新终端输入arm-linux-gnueabihf-gcc -v正常情况下会输出gcc version 7.5.0以及configured with相关信息。这里有个细节不要只执行arm-linux-gnueabihf-gcc不加参数那样大概率只会报“no input files”并不能说明编译器是否可用。-v参数能显示完整的配置和版本信息量最足。顺便再检查以下几个工具的可用性arm-linux-gnueabihf-gcc -v arm-linux-gnueabihf-g -v arm-linux-gnueabihf-ld --version arm-linux-gnueabihf-strip --version如果都能正常输出版本说明PATH里已经能找到这套工具链环境变量配置基本成功。接下来就是实际编译验证了。4. 实操编译验证从Hello程序到内核模块4.1 交叉编译一个用户态程序光看版本号还不够我们实际写个程序编译一下确认整套流程真的能用。新建一个hello.c#include stdio.h int main(void) { printf(Hello from ARM!\n); return 0; }然后执行交叉编译arm-linux-gnueabihf-gcc -o hello hello.c编译完成后关键一步来了。用file命令查看产物格式file hello正常情况下你会看到类似这样的输出hello: 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看到“ARM, EABI5”就说明编译目标确实是ARM不是x86了。把这个hello文件拷贝到开发板上授予执行权限chmod x hello然后运行就能看到输出Hello from ARM!如果你在x86主机上直接执行这个hello文件系统会报“cannot execute binary file: Exec format error”这其实是好事说明交叉编译成功了——这个文件本来就不是给x86用的。4.2 在makefile项目中使用工具链前缀实际项目里没有人会在命令行里反复敲完整的工具链名更常见的是在makefile里用CROSS_COMPILE。比如编译U-Boot或者Linux内核时标准的调用方式是make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- orangepi_zero_defconfig make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- -j4这里CROSS_COMPILE变量的值必须以连字符结尾。因为makefile内部是这样拼接编译器的CC $(CROSS_COMPILE)gcc LD $(CROSS_COMPILE)ld如果你写成arm-linux-gnueabihf不带最后的连字符那CC就变成了arm-linux-gnueabihfgcc系统会提示找不到命令。这个细节我见过好几个人卡了很久就是差一个连字符。对于自己写的工程makefile里这样设置就很清晰CROSS_COMPILE ? arm-linux-gnueabihf- CC : $(CROSS_COMPILE)gcc CFLAGS : -Wall -O2 all: app app: main.c $(CC) $(CFLAGS) -o $ $^ clean: rm -f app这样在终端里直接make就可以编译出ARM程序。如果哪天换了工具链只需要改一个前缀变量非常方便。4.3 用交叉工具链调试和裁剪二进制除了编译套件里配套的工具也很有用。比如arm-linux-gnueabihf-strip可以把编译产物中的符号表去掉大大减小文件体积。对于存储空间紧张的嵌入式设备这一步很实际arm-linux-gnueabihf-strip hellostrip之前的hello可能有几十KBstrip之后可能只剩几KB。编译Debug版的时候不需要strip发布Release版时则建议做一下。还有个工具arm-linux-gnueabihf-readelf可以查看二进制文件的详细结构比如依赖哪些动态库arm-linux-gnueabihf-readelf -d hello在排查“板子上运行提示找不到某个.so库”这类问题时这个命令能帮你快速定位依赖关系。5. 环境变量避坑指南5.1 PATH顺序与多条工具链并存的坑最经典的环境变量坑是你明明配置了Linaro的bin目录但执行arm-linux-gnueabihf-gcc时系统却报“command not found”或者找到的却是另一个版本的编译器。原因多半是PATH里前面的路径抢先匹配了同名工具。如果你机器上装了多个交叉编译工具链或者某些IDE自带工具链它们可能都会提供arm-linux-gnueabihf-gcc这个文件。Linux系统在PATH中按顺序查找命令找到第一个就不再往后找。排查方法很简单which arm-linux-gnueabihf-gcc echo $PATH如果which显示的路径不是你刚配置的那个说明PATH顺序有问题。解决方式有两种一是把Linaro路径放在PATH开头export PATH/home/你的用户名/toolchains/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin:$PATH注意这里和前面的区别我把它放到了$PATH前面而不是后面。二是给不同的工具链做一个alias比如alias armgcc/home/你的用户名/toolchains/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc这样就算机器里有多个工具链你也能确保调用的是想要的版本。5.2 CROSS_COMPILE写错后缀的怪异现象刚才提到过CROSS_COMPILE必须以连字符结尾但还有一种更隐蔽的坑你用的是aarch64-linux-gnu工具链却在CROSS_COMPILE里写了arm-linux-gnueabihf-。这种情况下编译器可能确实存在但架构不匹配编译出来的文件拷到板子上运行直接报“Exec format error”或者在某些情况下编译过程中就开始报错。这类错误最迷惑人的点在于——命令确实能执行版本也能显示就是产物不对。我的经验是在配置好工具链后先做一次file验证不要等项目编译完、拷到板子上才发现问题。尤其是编译内核这种耗时很长的任务提前花两分钟验证能节省几个小时。5.3 shell配置不生效与重启丢失大家频繁踩的另一个坑是环境变量明明加进.bashrc了但新开的终端就是不生效。常见的几个原因第一你改的是.bashrc但当前用户默认shell是zsh或者fish。用echo $SHELL查看一下如果是/bin/zsh就要改.zshrc。第二Linux登录shell和非登录shell加载的文件不同。你在图形界面里开的终端往往是非登录shell它们加载的是.bashrc而不是.profile或.bash_profile。所以统一把配置写进.bashrc是对的但如果你写进了.profile某些终端可能不会加载。第三用sudo执行导致环境变量丢失。比如你执行sudo arm-linux-gnueabihf-gcc如果sudo配置了环境重置多数发行版默认如此即使当前终端有环境变量sudo环境下也是空的会报command not found。这时需要用sudo -E保留环境变量或者直接在sudo应用的配置里加上工具链路径。5.4 与系统gcc混用导致的头文件错误还有一种很隐蔽的情况你在makefile里没用CC变量而是直接写了gcc。这时候编译可能会过只要代码没用到特殊头文件一旦用了标准库头文件就会出现“stdio.h: No such file or directory”这类错误。原因很简单——系统gcc默认找的是x86的头文件路径里面压根没有ARM架构对应的头文件。而Linaro工具链把ARM的libc头文件都放在了自己的include目录下两者不能混用。所以在配置环境变量时我建议同时在.bashrc里明确把CC指向交叉编译器export CCarm-linux-gnueabihf-gcc很多第三方项目的makefile默认信任CC变量这样设置之后至少能少踩一个坑。6. 常见问题排查速查表6.1 command not found可能原因排查方法解决方案PATH未包含工具链bin目录echo $PATH查看在.bashrc中添加export PATH...当前shell不是bashecho $SHELL改用对应的.zshrc/.profile配置配置后未source新开终端重试执行source ~/.bashrcsudo环境变量被重置sudo which gcc验证用sudo -E或配置sudoers保留环境变量这个报错是最常见的但也是最容易排查的。明确报错的主体是谁然后顺着echo $PATH、which、ls这些命令一层层查基本几分钟就能定位。6.2 No such file or directory这个报错有点迷惑性。你明明看到文件存在执行时却提示找不到。经典的例子是在64位Ubuntu上执行32位的工具链bash: ./arm-linux-gnueabihf-gcc: No such file or directory这不是文件不存在而是Linux缺少运行这个二进制所需的32位动态链接器兼容库。旧版本Linaro工具链可能出现这种情况解决方案是安装对应平台的兼容库sudo apt update sudo apt install lib32z1 lib32ncurses6 lib32stdc6新版的Linaro工具链基本都是纯64位程序这种情况已经很少见了但如果你下载的是老版本或者某些第三方工具链依然可能碰到。用file命令查看一下工具链里的gcc文件格式file ~/toolchains/.../bin/arm-linux-gnueabihf-gcc如果输出里显示“ELF 32-bit LSB executable”那就是32位程序需要装上述依赖。6.3 头文件找不到或链接失败这类问题通常表现为error: stdio.h: No such file or directory或者cannot find -lc先确认你用的是交叉编译器而不是系统gcc。执行which arm-linux-gnueabihf-gcc确认路径。然后检查编译命令里是否加了正确的参数有些项目的makefile需要你显式传递CFLAGS比如make CROSS_COMPILEarm-linux-gnueabihf- ARCHarm对于Linux内核这类大型项目还需要设置ARCH环境变量如果不设置内核构建系统会默认按本机架构来处理然后一路报错。还有一种情况包含头文件报错是因为sysroot不对。Linaro工具链的sysroot默认定位在工具链目录内部如果你把工具链的lib目录或include目录挪了位置编译器就找不到库了。解决方法是恢复目录结构或者通过--sysroot参数指定正确的路径。6.4 在x86主机上运行ARM程序的报错编译完成后在x86主机上直接运行ARM可执行文件会出现bash: ./hello: cannot execute binary file: Exec format error这个报错在我的经验里反而是“好事”说明交叉编译成功了。有些同学会以为编译出了问题其实不然——x86内核不认ARM的二进制格式这完全正常。正确做法是把文件拷贝到目标开发板上运行。如果你在开发板上运行却提示/lib/ld-linux-armhf.so.3: No such file or directory这说明你的工具链和板子系统库不匹配。可能你用了gnueabihf工具链编译但板子上跑的系统是纯armel软浮点系统没有armhf的动态链接器。这种情况只能换用与目标系统ABI匹配的工具链或者在编译时加上-mfloat-abisoftfp之类的参数。所以在选工具链之前务必要先确认板子系统的ABI版本这个信息可以用板子上执行readelf -A /bin/ls查看Tag_ABI_VFP_args字段来确认。结尾的实操体会工具链本身并不复杂但牵扯到环境变量、架构、ABI这些问题时第一次接触确实容易栽跟头。我自己刚入行时也经历过工具链下载了三天各种报错Google了一整晚最后发现只是.bashrc里少写了一个冒号。所以我建议所有刚接触交叉编译的开发者都按这个流程走一遍先确认架构和ABI再下载对应工具链解压后立即验证配置环境变量后新开终端再次验证最后用一个hello程序和file命令做完整测试。这套流程走通了后面编译内核、移植驱动、交叉编译Qt应用才会有底气。顺便说一个我后期一直在用的小习惯在makefile项目里把工具链前缀单独抽出来放到一个env.mk文件里不同项目引用同一个文件。这样换工具链版本时只需要改一个地方而且不会因为某个终端忘了source环境变量而导致编译环境和别人不一致。嵌入式的坑很多但环境配置这个坑只要你把原理弄清楚了就能一次避开。
