为什么要交叉编译
交叉编译其实是相对于本地编译(native build)来说的,我相信大家最开始学习 C/C++ 这些语言的时候,都是在电脑上写程序,然后在电脑上编译生成可执行文件,最后在电脑上运行。程序的编辑——》编译——》运行,整个过程都是在一台 X86 电脑上。
当我们开始接触嵌入式开发后,事情变的不一样了,你在电脑上写程序,在电脑上编译出可执行文件,最后这个可执行文件需要下载到你的开发板上运行。程序最后运行的环境变了,比如你的开发板是基于 Arm 的——程序在 X86 上编辑,编译,最终运行在另一个和 X86 完全不同的架构的 Arm 芯片上。
之所以整个流程变成了这个样子,这是由嵌入式系统的特性决定的:一般嵌入式系统里面使用的芯片性能都比较弱,而且绝大部分都不能像 X86 一样运行 Windows/Ubuntu 桌面系统,即使能运行,性能也很弱,无法给你提供一个在开发板上写代码、编译代码的环境。所以我们还是离不开 X86 电脑强大高效的桌面环境进行软件开发。
但是这样有一个问题,X86、Arm、MIPS、RISC-V 这些芯片,它们的指令集是由不同的组织或者公司设计的,彼此并不兼容——Arm 和 MIPS 的 CPU 无法运行以 X86 的指令集编码的程序,反之亦然。所以我们要在 X86 的电脑上编译出能够在 Arm 上运行的程序,我们必须明确告诉编译器,编译生成的可执行文件需要以 Arm 指令集的标准编码。为了让这个流程变得简单,开发者们为不同的芯片开发了不同的编译器,比如针对 Arm 平台的 arm-linux-gcc,针对 mips 平台的 mips-linux-gnu-gcc,这些编译器都是基于 GCC 针对具体的架构指令集进行对应配置,所以它们在运行的时候就就会生成和该目标平台对应的可执行文件。
这篇文章主要讲 Arm 的交叉编译,所以这里后面都以 Linux 开发环境下的 Arm gcc 为例。
工具链的种类
GCC 的命名规则为: arch [-vendor] [-os] [-(gnu)eabi]-gcc
比如 arm-linux-gnueabi-gcc ,arm-none-eabi-gcc, aarch64-linux-gnu-gcc
带 [] 的是可选部分。
arch: 芯片架构,比如 32 位的 Arm 架构对应的 arch 为 arm,64 位的 Arm 架构对应的 arch 为 aarch64。
vendor :工具链提供商,大部分工具链名字里面都没有包含这部分。
os :编译出来的可执行文件(目标文件)针对的操作系统,比如 Linux。
arm-none-eabi-gcc 一般适用用于 Arm Cortex-M/Cortex-R 平台,它使用的是 newlib 库。
arm-linux-gnueabi-gcc 和 aarch64-linux-gnu-gcc 适用于 Arm Cortex-A 系列芯片,前者针对 32 位芯片,后者针对 64 位芯片,它使用的是 glibc 库。可以用来编译 u-boot、linux kernel 以及应用程序。
另外需要补充一点的是,32 位的 Arm 和 64 位的 Arm,它们的指令集是不同的,所以需要使用不同的工具链。当然,Arm64 为了保证前向兼容,提供了一个 32 位的兼容模式,所以我们用 arm-linux-gnueabi-gcc 编译的应用程序也是可以直接在Arm64 的系统上运行的,但是 Linux Kernel 和 U-Boot 就不行,除非你提前把 CPU 切换到 32 位模式。曾经有个项目使用了一颗四核的 Arm64 芯片,但是内存只有64M,为了节省空间,在 CPU 运行到 U-Boot 之前,我们就把它切到了 32 位模式,后面的 U-Boot、Linux Kernel,应用全部都用 32 位编译,加上 Thumb 指令集,节省了不少空间。
工具链的下载安装
下载地址
现在 Arm 平台上用的最广泛的工具链是 Linaro 发布的,大家可以到 Linaro 官网下载