浅析gcc、arm-linux-gcc和arm-elf-gcc的关系

The GNU Compiler Collection，通常简称 GCC，是一套由 GNU 开发的编译器集，为什么是编辑器集而不是编译器呢？那是因为它不仅支持 C 语言编译，还支持 C++， Ada，Objective C 等许多语言。另外 GCC 对硬件平台的支持，可以所无所不在，它不仅支持 X86处理器架构, 还支持 ARM, Motorola 68000, Motorola 8800，AtmelAVR，MIPS 等处理器架构。

本文引用地址：http://www.eepw.com.cn/article/201611/319970.htm

二、GCC的组成结构

GCC 内部结构主要由 Binutils、gcc-core、Glibc 等软件包组成。

1. Binutils：它是一组开发工具，包括连接器，汇编器和其他用于目标文件和档案的工具。关于 Binutils 的介绍可以参考 Binutils 简单介绍。这个软件包依赖于不同的目标机的平台。因为不同目标机的指令集是不一样的，比如 arm 跟 x86 就不一样。
2. gcc-core：顾明之意是 GCC 的核心部分，这部分是只包含 c 的编译器及公共部分，而对其他语言（C++、Ada 等）的支持包需要另外安装，这也是 GCC 为何如此强大的重要原因 。gcc-core依赖于 Binutils。
3. Glibc：包含了主要的 c 库，这个库提供了基本的例程，用于分配内存，搜索目录，读写文件，字符串处理等等。kernel 和 bootloader不需要这个库的支持。

举例描述下上面 3 个包是如何进行运作的。有一个 c 源文件 test.c 源码如下：

编译命令为： gcc -o test test.c 编译生成 test 可执行文件。gcc 编译流程分为四个步骤：预处理、编译 、汇编、链接。个人认为预处理和编译主要由 gcc-core 来完成，汇编和链接主要由 Binutils 来完成。那么何时用到 glibc 呢？看到源码中的 printf 函数没有，这个函数在 GCC 中是以库函数的形式存在，这个库函数在 glibc 库中，在 stdio.h 头文件中被声明。
总的来说，如果真正了解了上面 3 个软件包的作用，自然就明白 GCC 是如何工作的。

三、交叉编译

交叉编译（或交叉建立）是这样一种过程，它在一种机器结构下编译的软件将在另一种完全不同的机器结构下执行。一个常见的例子是在 PC 机上为运行在基于 ARM、PowerPC或 MIPS 的目标机的编译软件。幸运的是，GCC 使得这一过程所面临的困难要比听起来小得多。GCC 中的一般工具通常都是通过在命令行上调用命令（如 gcc）来执行的。在使用交叉编译的情况下，这些工具将根据它编译的目标而命名。例如，要使用交叉工具链为 ARM 机器编译简单的 Hello World 程序，你可以运行如下所示的命令：使用如下命令编译并测试这个代码：arm-linux-gcc -o hello hello.c。

四、arm-linux-gcc

arm-linux-gcc 是基于 ARM 目标机的交叉编译软件，arm-linux-gcc 跟 GCC 所需的安装包不同，但仅仅是名字不同而已，这是为什么呢？

x86 跟 ARM 所使用的指令集是不一样的，所以所需要的 binutils 肯定不一样；上面提到过 gcc-core 是依赖于 binutils 的，自然 ARM 跟 x86 所使用的 gcc-core 包也不一样；glibc 一个 c 库，最终是以库的形式存在于编译器中，自然 ARM 所使用的 glibc 库跟 x86 同样也不一样，其它的依此类推。

五、arm-elf-gcc

arm-elf-gcc 跟 arm-linux-gcc 一样，也是是基于 ARM 目标机的交叉编译软件。但是它们不是同一个交叉编译软件，两者是有区别的，两者区别主要在于使用不同的 C 库文件。arm-linux-gcc 使用 GNU 的 Glibc，而 arm-elf-gcc 一般使用 uClibc/uC-libc 或者使用 RedHat专门为嵌入式系统的开发的C库newlib。只是所应用的领域不同而已，Glibc是针对PC开发的，uClibc/uC-libc是与Glibc API兼容的小型化C语言库，实现了Glibc部分功能。

六、uClibc/uC-libc

uClinux有两个经常使用的libc库：uC-libc和uClibc。虽然两者名字很相似，其实有差别，下面就简单的介绍一下二者的不同之处。uC -libc是最早为uClinux开发的库，是Jeff Dionne和Kenneth Albanowski为在EKLs项目中支持m68000在Linux-8086 C库源码上移植的。uC-libc是一个完全的libc实现，但其中有一些api是非标准的，有些libc的标准也没有实现。uC-libc稳定地支持 m68000，ColdFire和没有MMU的ARM。其主要设计目标是“小”、“轻”，并尽量与标准一致，虽然它的API和很多libc兼容，但是似乎并不像它期望的那样和所有标准一致。

uClibc就是为了解决这个问题从uC-libc中发展出来的。它的所有API都是标准的(正确的返回类型，参数等等)，它弥补了uC-libc中没有实现的libc标准，现在已经被移植到多种架构中。一般来讲，它尽量兼容glibc以便使应用程序用uClibc改写变的容易。uClibc能够在标准的 VM linux和uClinux上面使用。为了应用程序的简洁，它甚至可以在许多支持MMU的平台上被编译成共享库。Erik Anderson在uClibc背后做了很多的工作。uClibc支持许多系列的处理器：m68000，Coldfire，ARM，MIPS，v850， x86，i960，Sparc，SuperH，Alpha，PowerPC和Hitachi 8。不断增加的平台支持显示uClibc能够很容易的适应新的架构。uClinux发行版提供了环境能够让你选择使用uC-libc或是uClibc编译。对于m68000和Coldfire平台来说，选择uC-libc还是稍微好一点，因为它支持共享库，而共享库是这些cpu经常使用的 libc。uClibc也几乎和所有的平台都能很好的工作。

newlib 是一个用于嵌入式系统的开放源代码的C语言程序库，由libc和libm两个库组成，特点是轻量级，速度快，可移植到很多CPU结构上。newlib实现了许多复杂的功能，包括字符串支持，浮点运算，内存分配(如malloc)和I/O流函数(printf，fprinf()等等)。其中libc提供了c 语言库的实现，而libm提供了浮点运算支持。

七、C语言库的选择

在为ARM交叉编译gcc编译器时，对gcc指定不同的配置选项时，使用的C语言库就不同，gcc编译器默认使用Glibc，也可以使用 uClibc/uC-libc(基本兼容Glibc API)，当使用--with-newlib时，gcc编译器不使用Glibc。当没有交叉编译Glibc时，可以使用--with-newlib禁止连接Glibc而编译bootstrap gcc编译器。从gcc源目录下的config/arm中的t-linux和t-arm-elf中可以看出，不同的--target也影响gcc连接C语言库，t-linux(--target=arm-linux)默认使用Glibc，-arm-elf(--target=arm-elf)使用- Dinhibit_libc禁止连接Glibc，这时我们就可以使用newlib等其他C语言库编译GCC工具链。

虽然GCC工具链配置了不同的的C语言库，但由于这些C语言库都可以用来支持GCC，它们对核心数据的处理上不存在较大出入。因而arm-linux-* 和 arm-elf-*区别主要表现在C语言库的实现上，例如不同系统调用，不同的函数集实现，不同的ABI/启动代码以及不同系统特性等微小的差别。

arm-linux-*和 arm-elf-*的使用没有一个绝对的标准，排除不同库实现的差异，gcc可以编译任何系统。arm-linux-*和 arm-elf-*都可以用来编译裸机程序和操作系统，只是在遵循下面的描述时系统程序显得更加协调：

• arm-linux-*针对运行linux的ARM机器，其依赖于指定的C语言库Glibc，因为同样使用Glibc的linux而使得arm-linux-*在运行linux的ARM机器上编译显得更加和谐。
• arm-elf-*则是一个独立的编译体系，不依赖于指定的C语言库Glibc，可以使用newlib等其他C语言库，不要求操作系统支持，当其使用为嵌入式系统而设计的一些轻巧的C语言库时编译裸机程序(没有linux等大型操作系统的程序)，如监控程序，bootloader等能使得系统程序更加小巧快捷。