Linux开发讲课31---Linux开发环境下的Arm gcc交叉编译介绍

为什么要交叉编译

交叉编译其实是相对于本地编译(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 指令集，节省了不少空间。