linux基础篇（一）——GCC和Makefile编译过程
linux基础篇（二）——静态和动态链接
ARM裸机篇（一）——i.MX6ULL介绍
ARM裸机篇（二）——i.MX6ULL启动过程
ARM裸机篇（三）——i.MX6ULL第一个裸机程序
ARM裸机篇（四）——重定位和地址无关码
ARM裸机篇（五）——异常和中断
linux系统移植篇（一）—— linux系统组成
linux系统移植篇（二）—— Uboot使用介绍
linux系统移植篇（三）—— Linux 内核使用介绍
linux系统移植篇（四）—— 根文件系统使用介绍
linux驱动开发篇（一）—— Linux 内核模块介绍
linux驱动开发篇（二）—— 字符设备驱动框架
linux驱动开发篇（三）—— 总线设备驱动模型
linux驱动开发篇（四）—— platform平台设备驱动
使用文本文件编写一个Hello World程序，文件名命名为hello.c：
#include <stdio.h>
int main()
{
printf("Hello World\n");
return 0;
}
然后我们如何使这个Hello World程序按我们预想的样子执行呢？平常我们都会使用各种集成开发环境(IDE),比如 Visual Studio、Keil等，这样的IDE一般都将编译和链接的过程一步完成，它们提供的默认配置、编译和链接参数对我们日常使用而言已经足够了，但是我们往往也会被这些复杂的集成工具所提供的强大功能所迷惑，很多系统软件的运行机制与机理被掩盖。
接下来请思考以下几个问题：
看似简单的一个Hello World程序想要运行起来，背后其实隐藏了大量的细节，Hello World程序从源代码到变成可执行文件的一个简单流程大概如下图所示：
源代码大家都已经比较熟悉了，接下来我会通过几篇文章来简单的介绍一下剩下步骤和使所使用到的工具，并尝试挖掘出Hello World程序背后隐藏的细节。
GCC 编译工具链（toolchain）是指以 GCC 编译器为核心的一整套工具，用于把源代码转化成可执行应用程序。它主要包含以下三部分内容：
• GCC 编译器 : 用于完成预处理和编译过程，例如把 C 代码转换成汇编代码。
• glibc：包含了主要的 C 语言标准函数库， C 语言中常常使用的打印函数 printf、 malloc 函数就在 glibc 库中。
• Binutils ：除GCC编译器外的一系列小工具包括了链接器ld，汇编器as、目标文件格式查看器readelf等。
从直观的角度讲，编译器就是把高级语言翻译成机器语言的一个工具。编译过程一般可以分为6步：词法分析、语法分析、语义分析、源代码优化、目标代码生成与优化。
中间代码使得编译器可以分为前端和后端。编译器前端负责产生机器无关的中间代码，编译器后端将中间代码转换成目标机器代码。
我们通常说的GCC是一套完整的编译器软件，包括编译器前端和后端。
常见的编译器前端和后端如下图所示：
| 编译器 | 编译器前端 | 编译器后端 |
|---|---|---|
| GCC编译器 | GCC | GCC |
| LLVM-GCC编译器 | GCC | LLVM |
| LLVM编译器 | Clang | LLVM |
GCC for ARM 则是基于 GCC 开发的，用来编译生成 ARM 内核可执行文件的编译套件，俗称 ARM 交叉编译套件。
ARM 交叉编译工具链的命名规则：
arch [-vendor] [-os] [-(gnu)eabi] [-gcc]
如果同时没有 vendor 和 os 支持，则只用一个 none 代替。
linux系统默认安装了GCC 编译工具链，当我们使用GCC来编译Hello World程序时，只需要使用简单的命令：
> gcc hello.c -o hello
> ./hello
Hello World
事实上，上述过程可以分解为4个步骤，分别是预处理、编译、汇编和链接
如图所示：
gcc [选项] 文件名
> gcc -E hello.c -o hello.i
打开hello.i可以发现#include <stdio.h>已经被相关内容给替换掉了。
#对hello.i进行编译：
> gcc -S hello.i -o hello.s
打开hello.s,可以看到编译完成后生成的便是汇编代码。
> gcc -c hello.s -o hello.o
hello.c的第一行代码#include <stdio.h>，经过gcc -E hello.c -o hello.i后，#include <stdio.h>被替换掉了。
我们知道printf函数的声明是在stdio.h这个头文件中，那么gcc是怎么找到stdio.h这个头文件的呢，换句话说stdio.h这个头文件在系统的什么地方？
还有hello.c的第二行代码int main()，为什么一定要写成main才行？
这些问题都与glibc库和链接有关，下一节来专门讲解glibc库和链接。
只有一个hello.c文件，非常简单，所以直接执行下面的指令进行编译也非常方便。
> gcc hello.c -o hello
> ./hello
Hello World
但是实际上一个工程不可能只有一个文件，当一个工程中有很多C源文件和H头文件时，再直接使用编译器指令就非常麻烦了，比如编译多个文件：
gcc hello.c aaa.c bbb.c -o hello
而且哪怕你只是修改一个文件，也需要重新编译所有的文件，白白浪费了很多开发时间。 要解决这个问题，最好的方式就是把工程的编译规则写下来，让编译器自动加载该规则进行编译。 解决方法就是使用make和Makefile，这两个工具是搭配使用的:
make工具：它可以帮助我们找出项目里面修改变更过的文件，并根据依赖关系，找出受修改影响的其他相关文件，然后对这些文件按照规则进行单独的编译，这样一来，就能避免重新编译项目的所有的文件。
Makefile文件：上面提到的规则、依赖关系主要是定义在这个Makefile文件中的，我们在其中合理地定义好文件的依赖关系之后，make工具就能精准地进行编译工作。
我们管理一个项目工程，实质上就是管理项目文件间的依赖关系。 所以我们在学习和使用Makefile的时候，一定要牢牢抓住它这种面向依赖的思想， 心里一定要谨记，Makefile中所有的复杂、晦涩的语法都是更好地为解决依赖问题而存在的。
关于Makefile的详细使用可参考《跟我一起写Makefile》一书或GNU官方的make说 明文档：https://www.gnu.org/software/make/manual
野火的在线文档已经把如何快速使用Makefile讲解的比较清楚，我这里就不再重复了，可以进入链接学习：
https://doc.embedfire.com/linux/imx6/base/zh/latest/linux_app/makefile.html
源码要运行，必须先转成二进制的机器码。这是编译器的任务。
比如，下面这段源码:
#include <stdio.h>
int main()
{
printf("Hello World\n");
return 0;
}
要先用编译器处理一下才能运行，编译步骤如下：
> gcc hello.c -o hello
> ./hello
Hello World
对于复杂的项目，编译过程还必须分成三步。
> ./configure
> make
> make install
第一步 配置（configure）
编译器在开始工作之前，需要知道当前的系统环境，比如标准库在哪里、软件的安装位置在哪里、需要安装哪些组件等等。这是因为不同计算机的系统环境不一样，通过指定编译参数，编译器就可以灵活适应环境，编译出各种环境都能运行的机器码。这个确定编译参数的步骤，就叫做"配置"（configure）。
这些配置信息保存在一个配置文件之中，约定俗成是一个叫做configure的脚本文件。通常它是由autoconf工具生成的。编译器通过运行这个脚本，获知编译参数。
configure脚本已经尽量考虑到不同系统的差异，并且对各种编译参数给出了默认值。如果用户的系统环境比较特别，或者有一些特定的需求，就需要手动向configure脚本提供编译参数：
$ ./configure --prefix=/www --with-mysql
上面代码是php源码的一种编译配置，用户指定安装后的文件保存在www目录，并且编译时加入mysql模块的支持。
第二步 确定标准库和头文件的位置
源码肯定会用到标准库函数（standard library）和头文件（header）。它们可以存放在系统的任意目录中，编译器实际上没办法自动检测它们的位置，只有通过配置文件才能知道。
编译的第二步，就是从配置文件中知道标准库和头文件的位置。一般来说，配置文件会给出一个清单，列出几个具体的目录。等到编译时，编译器就按顺序到这几个目录中，寻找目标。
第三步 确定依赖关系
对于大型项目来说，源码文件之间往往存在依赖关系，编译器需要确定编译的先后顺序。假定A文件依赖于B文件，编译器应该保证做到下面两点。
（1）只有在B文件编译完成后，才开始编译A文件。
（2）当B文件发生变化时，A文件会被重新编译。
编译顺序保存在一个叫做makefile的文件中，里面列出哪个文件先编译，哪个文件后编译。而makefile文件由configure脚本运行生成，这就是为什么编译时configure必须首先运行的原因。
在确定依赖关系的同时，编译器也确定了，编译时会用到哪些头文件。
第四步 头文件的预编译（precompilation）
不同的源码文件，可能引用同一个头文件（比如stdio.h）。编译的时候，头文件也必须一起编译。为了节省时间，编译器会在编译源码之前，先编译头文件。这保证了头文件只需编译一次，不必每次用到的时候，都重新编译了。
不过，并不是头文件的所有内容，都会被预编译。用来声明宏的#define命令，就不会被预编译。
第五步 预处理（Preprocessing）
预编译完成后，编译器就开始替换掉源码中bash的头文件和宏。以本文开头的那段源码为例，它包含头文件stdio.h，替换后的样子如下。
extern int printf(const char *, FILE *);
int main(void){
printf("Hello World\n");
return 0;
}
为了便于阅读，上面代码只截取了头文件中与源码相关的那部分，即fputs和FILE的声明，省略了stdio.h的其他部分（因为它们非常长）。另外，上面代码的头文件没有经过预编译，而实际上，插入源码的是预编译后的结果。编译器在这一步还会移除注释。
这一步称为"预处理"（Preprocessing），因为完成之后，就要开始真正的处理了。
第六步 编译（Compilation）
预处理之后，编译器就开始生成机器码。对于某些编译器来说，还存在一个中间步骤，会先把源码转为汇编码（assembly），然后再把汇编码转为机器码。
下面是本文开头的那段源码转成的汇编码。
.file "test.c"
.section .rodata.LC0:
.string "Hello, world!\n"
.text .globl main .type main, @functionmain:.LFB0:
.cfi_startproc
pushq %rbp .cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp .cfi_def_cfa_register 6
movq stdout(%rip), %rax
movq %rax, %rcx
movl $14, %edx
movl $1, %esi
movl $.LC0, %edi
call fwrite
movl $0, %eax
popq %rbp .cfi_def_cfa 7, 8
ret .cfi_endproc.LFE0:
.size main, .-main .ident "GCC: (Debian 4.9.1-19) 4.9.1"
.section .note.GNU-stack,"",@progbits
这种转码后的文件称为对象文件（object file）。
第七步 链接（Linking）
对象文件还不能运行，必须进一步转成可执行文件。如果你仔细看上一步的转码结果，会发现其中引用了stdout函数和fwrite函数。也就是说，程序要正常运行，除了上面的代码以外，还必须有stdout和fwrite这两个函数的代码，它们是由C语言的标准库提供的。
编译器的下一步工作，就是把外部函数的代码（通常是后缀名为.lib和.a的文件），添加到可执行文件中。这就叫做连接（linking）。这种通过拷贝，将外部函数库添加到可执行文件的方式，叫做静态连接（static linking），后文会提到还有动态连接（dynamic linking）。
make命令的作用，就是从第四步头文件预编译开始，一直到做完这一步。
第八步 安装（Installation）
上一步的连接是在内存中进行的，即编译器在内存中生成了可执行文件。下一步，必须将可执行文件保存到用户事先指定的安装目录。
表面上，这一步很简单，就是将可执行文件（连带相关的数据文件）拷贝过去就行了。但是实际上，这一步还必须完成创建目录、保存文件、设置权限等步骤。这整个的保存过程就称为"安装"（Installation）。
第九步 操作系统连接
可执行文件安装后，必须以某种方式通知操作系统，让其知道可以使用这个程序了。比如，我们安装了一个文本阅读程序，往往希望双击txt文件，该程序就会自动运行。
这就要求在操作系统中，登记这个程序的元数据：文件名、文件描述、关联后缀名等等。Linux系统中，这些信息通常保存在/usr/share/applications目录下的.desktop文件中。另外，在Windows操作系统中，还需要在Start启动菜单中，建立一个快捷方式。
这些事情就叫做"操作系统连接"。make install命令，就用来完成"安装"和"操作系统连接"这两步。
第十步 生成安装包
写到这里，源码编译的整个过程就基本完成了。但是只有很少一部分用户，愿意耐着性子，从头到尾做一遍这个过程。事实上，如果你只有源码可以交给用户，他们会认定你是一个不友好的家伙。大部分用户要的是一个二进制的可执行程序，立刻就能运行。这就要求开发者，将上一步生成的可执行文件，做成可以分发的安装包。
所以，编译器还必须有生成安装包的功能。通常是将可执行文件（连带相关的数据文件），以某种目录结构，保存成压缩文件包，交给用户。
第十一步 动态连接（Dynamic linking）
正常情况下，到这一步，程序已经可以运行了。至于运行期间（runtime）发生的事情，与编译器一概无关。但是，开发者可以在编译阶段选择可执行文件连接外部函数库的方式，到底是静态连接（编译时连接），还是动态连接（运行时连接）。所以，最后还要提一下，什么叫做动态连接。
前面已经说过，静态连接就是把外部函数库，拷贝到可执行文件中。这样做的好处是，适用范围比较广，不用担心用户机器缺少某个库文件；缺点是安装包会比较大，而且多个应用程序之间，无法共享库文件。
动态连接的做法正好相反，外部函数库不进入安装包，只在运行时动态引用。好处是安装包会比较小，多个应用程序可以共享库文件；缺点是用户必须事先安装好库文件，而且版本和安装位置都必须符合要求，否则就不能正常运行。
现实中，大部分软件采用动态连接，共享库文件。这种动态共享的库文件，Linux平台是后缀名为.so的文件，Windows平台是.dll文件，Mac平台是.dylib文件。
参考文章：
gcc&arm-linux-gcc编译过程详解