摘要：编译&链接对C&C++程序员既熟悉又陌生，熟悉在于每份代码都要经历编译&链接过程，陌生在于大部分人并不会刻意关注编译&链接的原理。本文通过开发过程中碰到的四个典型问题来探索64位linux下C++编译&链接的那些事。 编译原理：
将如下最简单的C++程序（main.cpp）编译成可执行目标程序，实际上可以分为四个步骤:预处理、编译、汇编、链接，可以通过
g++ main.cpp –v看到详细的过程，不过现在编译器已经把预处理和编译过程合并。
预处理：g++ -E main.cpp -o main.ii，-E表示只进行预处理。预处理主要是处理各种宏展开；添加行号和文件标识符，为编译器产生调试信息提供便利；删除注释；保留编译器用到的编译器指令等。
编译：g++ -S main.ii –o main.s，-S表示只编译。编译是在预处理文件基础上经过一系列词法分析、语法分析及优化后生成汇编代码。
汇编：g++ -c main.s –o main.o。汇编是将汇编代码转化为机器可以执行的指令。
链接：g++ main.o。链接生成可执行程序，之所以需要链接是因为我们代码不可能像main.cpp这么简单，现代软件动则成百上千万行，如果写在一个main.cpp既不利于分工合作，也无法维护，因此通常是由一堆cpp文件组成，编译器分别编译每个cpp，这些cpp里会引用别的模块中的函数或全局变量，在编译单个cpp的时候是没法知道它们的准确地址，因此在编译结束后，需要链接器将各种还没有准确地址的符号（函数、变量等）设置为正确的值，这样组装在一起就可以形成一个完整的可执行程序。
问题一：头文件遮挡在编译过程中最诡异的问题莫过于头文件遮挡，如下代码中main.cpp包含头文件common.h，真正想用的头文件是图中最右边那个包含name
成员的文件（所在目录为./include），但在编译过程中中间的common.h（所在目录为./include1）抢先被发现，导致编译器报错：Test结构没有name成员，对程序员来讲，自己明明定义了name成员，居然说没有name这个成员，如果第一次碰到这种情况可能会怀疑人生。应对这种诡异的问题，我们可以用-E参数看下编译器预处理后的输出，如下图。
预处理文件格式如下：# linenum filename flag，表示之后的内容是从文件名为filaname的文件中第linenum行展开的，flag的取值可以是1,2,3,4，可以是用空格分开的多值，1表示接下来要展开一个新文件；2表示一个文件展开完毕；3表示接下来内容来自一个系统头文件；4表示接下来的内容应该看做是extern C形式引入的。
从展开后的输出我们可以清楚地看到Test结构确实没有定义name这个成员，并且Test这个结构是在./include1中的common.h中定义的，到此真相大白，编译器压根就没用我们定义的Test结构，而是被别的同名头文件截胡了。我们可以通过调整-I或者在头文件中带上部分路径更详细制定头文件位置来解决。
目标文件：编译链接最终会生成各种目标文件，Linux下目标文件格式为ELF（Executable Linkable Format），详细定义见/usr/include/elf.h头文件，常见的目标文件有：可重定位目标文件，也即.o结尾的目标文件，当然静态库也归为此类；可执行文件，比如默认编译出的a.out文件；共享目标文件.so；核心转储文件，也就是core dump后产出的文件。Linux文件格式可以通过file命令查看。
一个典型的ELF文件格式如下图所示，文件有两种视角：编译视角，以section头部表为核心组织程序；运行视角，程序头部表以segment为核心组织程序。这么做主要是为了节约存储，很多细碎的section在运行时由于对齐要求会导致很大的内存浪费，运行时通常会将权限类似的section组织成segment一起加载。
通过命令objdump和readelf可以查看ELF文件的内容。