c程序编译连接的原理与过程
从C/C++源程序到可执行文件要经历两个阶段：(1)编译器将源文件编译成汇编代码，然后由汇编器(assembler翻译成机器代码(再加上其它相关信息)后输出到一个个目标文件(objectfile,VC的编译器编译出的目标文件默认的后缀名是.obj) 中；(2)链接器(linker)将一个个的目标文件(或许还会有若干系统库)链接在一起生成一个完整的可执行文件。
C 语言提供了一种将多个目标文件打包成一个文件的机制，这就是静态链接库(staticlibrary)。开发者在链接时只需指定程序库的文件名，链接器就会自动到程序库中寻找那些应用程序确实用到的目标模块，并把(且只把)它们从库中拷贝
出来参与构建可执行文件。
链接器按照所有目标文件和库文件出现在命令行中的顺序从左至右依次扫描它们，在此期间它要维护若干个集合:(1)集合E是将被合并到一起组成可执行文件的所有目标文件集合；⑵集合U是未解析符号(unresolvedsymbols,比如已
经被引用但是还未被定义的符号)的集合；(3)集合D是所有之前已被加入到E的目标文件定义的符号集合。一开始，E、U、D都是空的
(1) :对命令行中的每一个输入文件f，链接器确定它是目标文件还是库文
件，如果它是目标文件，就把f加入到E，并把f中未解析的符号和已定义的符号分别加入到U、D 集合中，然后处理下一个输入文件。
(2) :如果f是一个库文件，链接器会尝试把U中的所有未解析符号与f中各
目标模块定义的符号进行匹配。如果某个目标模块m定义了一个U中的未解析
符号，那么就把m加入到E中，并把m中未解析的符号和已定义的符号分别加入到U、D 集合中。不断地对f 中的所有目标模块重复这个过程直至到达一个不动点(fixed point)，此时U和D不再变化。而那些未加入到E中的f里的目标模块就被简单地丢弃，链接器继续处理下一输入文件。
(3) :如果处理过程中往D加入一个已存在的符号，或者当扫描完所有输入文件时U非空，链接器报错并停止动作。否则，它把E中的所有目标文件合并在一起生成可执行文件。
VC带的编译器名字叫cl.exe，它有这么几个与系统库有关的选项：/ML、
/MLd、/MT、/MTd、/MD、/MDd。
这些选项告诉编译器应用程序想使用什么版本的C标准程序库。/ML（缺省
选项）对应单线程静态版的标准程序库（libc.lib）；/MT 对应多线程静态版标准库（libcmt.lib），此时编译器会自动定义_MT宏；/MD对应多线程DLL版（导入库msvcrt.lib, DLL是msvcrt.dll），编译器自动定义_MT和_DLL两个宏。后面加d的选项都会让编译器自动多定义一个_DEBUG宏，表示要使用对应标准库的调试版，因此/MLd 对应调试版单线程静态标准库（libcd.lib），/MTd 对应调试版多线程静态标准库（libcmtd.lib），/MDd对应调试版多线程DLL标准库（导入库msvcrtd.lib，DLL 是msvcrtd.dll）。在cl编译出的目标文件中会有一个专门的区域存放一些指导链接器如何工作的信息，其中有一种就叫缺省库（default library），这些信息指定了一个或多个库文件名，告诉链接器在扫描的时候也把它们加入到输入文件列表中（当然顺序位于在命令行中被指定的输入文件之后）。说到这里，我们先来做个小实验。写个顶顶简单的程序，然后保存为main.c :
/* main.c */
int main（） { return 0; }
用下面这个命令编译main.c（什么？你从不用命令行来编译程序？这个……）: cl /c main.c
/c 是告诉cl 只编译源文件，不用链接。因为/ML 是缺省选项，所以上述命令也相当于: cl /c /ML main.c。
如果没什么问题的话当前目录下会出现一个main.obj 文件，这就是我们可爱的目标文件。随便用一个文本编辑器打开它，搜索"defaultlib" 字符串，通常你就会看到这样的东西:"-defaultlib:LIBC-defaultlib:OLDNAMES。" 啊哈，没错，这就是保存在目标文件中的缺省库信息。我们的目标文件显然指定了两个缺省库，一个是单线程静态版标准库libc.lib（这与/ML选项相符），另外一个是oldnames.lib（它是为了兼容微软以前的C/C++开发系统）。
VC的链接器是link.exe,因为main.obj保存了缺省库信息，所以可以用
link main.obj libc.lib
或者
link main.obj
来生成可执行文件main.exe,这两个命令是等价的。但是如果你用
link main.obj libcd.lib
的话,链接器会给出一个警
告:"war nin gLNK4098:defaultlib"LIBC"co
nflictswithuseofotherlibs;use/NODEFAULTLIB
:library"，因为你显式指定的标准库版本与目标文件的缺省值不一致。通常来说,应该保证链接器合并的所有目标文件指定的缺省标准库版本一致,否则编
译器一定会给出上面的警告，而LNK2005和LNK1169链接错误则有时会出现有
时不会。那么这个有时到底是什么时候？呵呵,别着急,下面的一切正是为喜欢追根究底的你准备的。
建一个源文件，就叫mylib.c，内容如下:
/* mylib.c */
#include
void foo()
{
printf("%s","I am from mylib!\n");
}
用
cl /c /MLd mylib.c
命令编译，注意/MLd选项是指定libcd.lib为默认标准库。lib.exe是VC自带
的用于将目标文件打包成程序库的命令,所以我们可以用
lib /OUT:my.lib mylib.obj
将mylib.obj打包成库，输出的库文件名是my.lib。接下来把main.c改成：
/* main.c */
void foo();
int main()
{
foo();
return 0;
}
用
cl /c main.c
link main.obj my.lib
进行链接。这个命令能够成功地生成ma in .exe而不会产生LNK2005和
LNK1169链接错误，你仅仅是得到了一条警告信
息:"war nin gLNK4098:defaultlib"LIBCD"co
nflictswithuseofotherlibs;use/NODEFAULTLI B:library"。我们根据前文所述的扫描规则来分析一下链接器此时做了些啥。
一开始E、U、D都是空集，链接器首先扫描到main.obj，把它加入E集
合，同时把未解析的foo加入U，把main加入D,而且因为ma in .obj的默认标准库是libc.lib，所以它被加入到当前输入文件列表的末尾。
接着扫描my.lib，因为这是个库，所以会拿当前U中的所有符号(当然现在
就一个foo)与my.lib中的所有目标模块(当然也只有一个mylib.obj)依次匹配，看是否有模块定义了U中的符号。结果mylib.obj确实定义了foo，于是它被加入到E，foo 从U转移到D，mylib.obj弓I用的printf加入到U,同样地，mylib.obj 指定的默认标准库是libcd.lib，它也被加到当前输入文件列表的末尾(在libc.lib 的后面)。不断地在my.lib库的各模块上进行迭代以匹配U中的符号，直到U、
D 都不再变化。很明显，现在就已经到达了这么一个不动点，所以接着扫描下一个输入文件，就是libc.lib。
链接器发现libc.lib 里的printf.obj 里定义有printf ，于是printf 从U 移到D，而printf.obj被加入到E,它定义的所有符号加入到D,它里头的未解析符号加入到U。链接器还会把每个程序都要用到的一些初始化操作所在的目标模块(比
如crt0.obj 等)及它们所引用的模块(比如malloc . o bj 、free . o bj 等)自动加入到 E 中，并更新U和D以反应这个变化。事实上，标准库各目标模块里的未解析符号都可以在库内其它模块中找到定义，因此当链接器处理完libc.lib时，U一定
是空的。最后处理libcd.lib，因为此时U已经为空，所以链接器会抛弃它里面的所有目标模块从而结束扫描，然后合并E中的目标模块并输出可执行文件。
上文描述了虽然各目标模块指定了不同版本的缺省标准库但仍然链接成功的例子，接下来你将目睹因为这种不严谨而导致的悲惨失败。
修改mylib.c成这个样子：
#include
void foo()
{
// just a test , don't care memory leak
_malloc_dbg( 1, _NORMAL_BLOCK, __FILE__, __LINE__ );
}
其中_malloc_dbg不是ANSI C的标准库函数，它是VC标准库提供的malloc 的调试版，与相关函数配套能帮助开发者抓各种内存错误。使用它一定要定义_DEBUG 宏，否则预处理器会把它自动转为malloc。继续用
cl /c /MLd mylib.c
lib /OUT：my.lib mylib.obj
编译打包。当再次用
link main.obj my.lib
进行链接时，我们看到了什么？天哪，一堆的LNK2005加上个贵为"fatalerror"的LNK1169垫底，当然还少不了那个LNK4098链接器是不是疯了？不，
你冤枉可怜的链接器了，我拍胸脯保证它可是一直在尽心尽责地照章办事。
一开始E、U、D为空，链接器扫描main.obj,把它加入E,把foo加入U, 把main 加入D,把libc.lib加入到当前输入文件列表的末尾。接着扫描my.lib，foo从U转移到D，_malloc_dbg加入到U，libcd.lib加到当前输入文件列表的尾部。然后扫描libc.lib，这时会发现libc.lib里任何一个目标模块都没有定义_malloc_dbg （它只在调试版的标准库中存在），所以不会有任何一个模块因为_malloc_dbg而加入E,但是每个程序都要用到的初始化模块（如crtO.obj等）及它们所引用的模块（比如malloc.obj、free.obj等）还是会自动加入到E中，同时U和D被更新以反应这个变化。当链接器处理完libc.lib时，U只剩_malloc_dbg这一
个符号。最后处理libcd.lib，发现dbgheap.obj定义了_malloc_dbg,于是dbgheap.obj 加入到E,它里头的未解析符号加入U，它定义的所有其它符号也加入D,这时灾难便来了。之前malloc等符号已经在D中（随着libc.lib里的malloc.obj加入E而加入的），而dbgheap.obj又定义了包括malloc在内的许多同名符号，这引发了重定义冲突，链接器只好中断工作并报告错误。
现在我们该知道，链接器完全没有责任，责任在我们自己的身上。是我们粗心地把缺省标准库版本不一致的目标文件（main.obj）与程序库（my.lib）链接起来，导致了大灾难。解决办法很简单，要么用/MLd选项来重编译main.c;要么用/ML选项重编译mylib.c。在上述例子中，我们拥有库my.lib的源代码（mylib.c），所以可以用不同的选项重新编译这些源代码并再次打包。可如果使用的是第三方的库，它并没有提供源代码，那么我们就只有改变自己程序的编译选项来适应这些库了。但是如何知道库中目标模块指定的默认库呢？其实VC提供的一个小工具便可以完成任务，这就是dumpbin.exe。运行下面这个命令
dumpbin /DIRECTIVES my.lib
然后在输出中找那些"LinkerDirectives"引导的信息，你一定会发现每一处这样的信息都会包含若干个类似"-defaultlib:XXXX这样的字符串，其中XXXX便代表目标模块指定的缺省库名。
知道了第三方库指定的默认标准库，再用合适的选项编译我们的应用程序，就可以避免LNK2005和LNK1169链接错误。喜欢IDE的朋友，你一样可以到"Project 属性"->"C/C++"->'代码生成（codegeneration）"->"运行时库（run- timelibrary）" 项下设
置应用程序的默认标准库版本，这与命令行选项的效果是一样的。
底下是一些杂七杂八的xx：
一.预处理器-编译器-汇编器-链接器
预处理器会处理相关的预处理指令，一般是以"#"开头的指令。如：#include "xx.h" #define 等。
编译器把对应的*.cpp 翻译成*.s 文件（汇编语言）。
汇编器则处理*.s 生成对应的*.obj 文件
链接器把所有的*.obj 文件链接成一个可执行文件（?.exe）
2.编译单个文件:
记住IDE在bulid文件时只编译实现文件（如* cpp）来产生obj，在vc下你可以对某个?.cpp按下ctrl+f7单独编译它生成对应一个?.obj文件。在编译?.cpp时IDE会在?.cpp中按顺序处理用#include包括进来的头文件（如果该头文件中又#i nclude有文件，同样会按顺序跟进处理各个头文件，如此递归。。）
1. C++编译器对工程中的源文件*.CPP单独进行编译。在编译时，先由预处理器对预处理指令（#inelude、#define和#if）进行处理，在内存中输出翻译单元（一种临时文件）。编译器接受预处理的输出，将源代码转换称包含机器语言指令的目标文件（*.obj ）。
2. 注意：在编译过程中，头文件不参与编译。