静态编译与动态编译的区别

静态编译与动态编译的区别

　　动态编译的 可执行文件需要附带一个的 动态链接库，在执行时，需要调用其对应动态链接库中的命令。所以其优点一方面是缩小了执行文件本身的体积，另一方面是加快了编译速度，节省了 系统资源。缺点一是哪怕是很简单的程序，只用到了链接库中的一两条命令，也需要附带一个相对庞大的链接库；二是如果其他计算机上没有安装对应的 运行库，则用动态编译的可执行文件就不能运行。

　　静态编译就是 编译器在编译可执行文件的时候，将可执行文件需要调用的对应动态链接库(.so)中的部分提取出来，链接到可执行文件中去，使可执行文件在运行的时候不依赖于动态链接库。所以其优缺点与 动态编译的可执行文件正好互补。

 

 

 

 

用　　静态lib将导出声明和实现都放在lib中。编译后所有代码都嵌入到宿主程序

　　动态lib相当于一个h文件，是对实现部分（.dll文件）的导出部分的声明。编译后只是将导出声明部分编译到宿主程序中，运行时候需要相应的dll文件支持

　　lib文件是不对外公开的，不能查看一个编译过后的文件

　　有几个选择：

　　1。如果你查看有同名的dll文件，可以通过vc自带的depends查看dll接口

　　2。通过msdn看你使用的该lib包含的函数名，来查找其对应的头文件，头文件里面有整个lib的函数声明（可能不全）

　　3。查看vc或者其他工具安装目录下的src目录，查看函数的代码

　　lib文件是二进制文件，所以要查看它的内容，只能反汇编。

　　用编程语言,打开lib文件的办法有三个:

　　1、在object/library modules使用全路径名；

　　2、把*.lib放在VC的Lib目录中

　　3、修改project setting的Link->Input中的Addtional library path，加入你的目录。

　　LIB文件是库文件（与DLL文件相类似），供其它程序调用的，直接打不开。

编辑本段lib文件操作

　　一个lib文件是obj文件的集合。当然，其中还夹杂着其他一些辅助信息，目的是为了让编译器能够准确找到对应的obj文件。我们可以通过tlib.exe（在tc2.0下的根目录）来对lib文件进行操作，你可以把自己生成的obj文件通过tlib命令加入到一个lib文件中，也可以把lib文件内的obj文件进行删除操作，还可以把内部的obj文件给提取出来。明白了lib文件的大致结构以及对它的具体操作，在学习C语言的过程中，就会又多了一个切入点对C语言具体实现进行研究。

　　在command下，把当前目录设置为tlib.exe所在目录，然后输入tlib命令回车，此时显示的内容就是对tlib命令的详细解释，语法如下：

　　Syntax: TLIB libname [/C] [/E] commands, listfile

　　libname library file pathname

　　commands sequence of operations to be performed (optional)

　　listfile file name for listing file (optional)

　　A command is of the form: <symbol>modulename, where <symbol> is:

　　+ add modulename to the library

　　- remove modulename from the library

　　* extract modulename without removing it

　　-+ or +- replace modulename in library

　　-* or *- extract modulename and remove it

　　/C case-sensitive library

　　/E create extended dictionary

　　具体解释：

　　tlib libname [/C] [/E] commands, listfile

　　/C:大小写敏感标志。该选项不常用，此参数为可选项。

　　/E:建立扩展字典。建立扩展字典可以加速大的库文件的连接过程，此参数同样为可选项。

　　操作命令（可选项）：

　　+ obj文件名 把指定obj文件添加到lib文件中

　　- obj文件名 把指定obj文件从lib文件中删除

　　* obj文件名 导出指定的obj文件（导出后对应的obj文件在lib文件内仍然存在）

　　-+ obj文件名 替换指定的obj文件（前提是在lib文件中存在与指定obj文件同名的obj）

　　-* obj文件名 导出指定的obj文件（导出后把对应的obj文件从lib文件内删除）

　　lib文件中obj文件列表（可选项）

　　此参数说明了命令运行后，生成的对应lib文件的列表文件名。它记录了当前lib文件内obj文件列表

编辑本段Lib文件中的节

　　Lib格式只有四种类型的节（Section），即First Sec，Second Sec，Longname Sec和Obj Sec；其中Second Sec与Longname Sec是可选节，很多Lib文件中都没有。而开头的Singature只是一个标识，它相当于COFF目标文件中的魔法数字。它是一个长度为8的字符串，值为“!<arch>\n”。

　　First Sec 顾名思义，就是第一个节。它包含了库中所有的符号名以及这些符号所在的目标文件在库中的位置（绝对偏移）。

　　Second Sec 就是第二节。它的内容和First Sec是相同的。不同的是，Second Sec是一个有序表，通过它来查找库中的符号比通过First Sec来查找要快很多。

　　Longname Sec 是长名称节。这一节是一个字符串表。它包含了所有长目标文件名。如果后面的Obj Sec中没有给出相应的目标文件名，我们就要到这一节中来查找。

　　Obj Sec 就是目标文件节。这些节中存储着不同的目标文件的原始数据。

　　在库文件中，每一节都有两个部分。一个部分是头，另一个部分才是该节的数据；数据紧跟在头的后面。头描述了该节数据的类型、长度等信息。这些头的格式都是相同的。其结构用C语言描述如下：

　　typedef struct {

　　char Name[16]; // 名称

　　char Time[12]; // 时间

　　char UserID[6]; // 用户ID

　　char GroupID[6]; // 组ID

　　char Mode[8]; // 模式

　　char Size[10]; // 长度

　　char EndOfHeader[2];// 结束符

　　} SectionHeader;

　　可以看到，头中的数据全都是字符串。用字符串的好处是可以提高格式的兼容性，因为在不同的机器上，数据的排列方式是不同的。有的机器是以Little-Endian方式工作，还有的是以Big-Endian方式工作，它们互不兼容（这两种方式的区别！？请看我的《COFF格式》一文，其中的文件头一节有说明）。用字符串就不会有这种问题（后面我们将会遇到）。但它也有不方便的地方，就是必须把字符串转换成数值，多了一个步骤。

　　在这个结构中，最常用的Name、Size以及EndOfHeader三个成员。Name就是节的名称啦！Size也很好理解，就是该节数据的长度。现在要注意的就是这个EndOfHeader成员了！这个成员标志着头的结束，其内容为“`\n”（注意，这里没有打错，是两个字符“`”和“\n”）。怎么样？有点奇怪吧？为什么要有这个结束符？每一节的头长度一定，每节中的数据长度也知道。按顺序向下读不行吗？答案是：不行！因为每一节之间存在间隙！通常是一个字节或零个字节。如果是零个字节倒好，按顺序向下读是OK的。可是如果不为零的话，这样读就要错位了。要知道错位没有，只好用一个结束符来定位了。如果在读头的时候发现结束符不对，那就要一个字节一个字节地向下查找，直到找到结束符，才能算是对齐了。切记！切记！

　　当然，通过First Sec或Second Sec中给出的偏移来读数据就不存在这个问题。不会发生错位，放心读吧！

　　现在让我们来看看每一节中的数据是什么样子。

First Sec

　　第一节，通常就是Lib中的每一个小节。它的名称是“/”。其数据部分的结构如下：

　　typedef struct {

　　unsigned long SymbolNum; // 库中符号的数量

　　unsigned long SymbolOffset[n]; // 符号所在目标节的偏移

　　char StrTable[m]; // 符号名称字符串表

　　}FirstSec;

　　第一个成员SymbolNum是符号的数量。注意！它是以Big-Endian方式储存的（x86平台上的数据是以Little-Endian方式储存的。这里应该注意转换。后面给出的convert函数可以在Little-Endian格式与Big-Endian格式之间进行相互转换）。

　　第二个成员SymbolOffset是一个数组，它的长度n就是符号的数量，也就是SymbolNum。这个数组储存了每一个符号所在的目标节的偏移。我们可以方便地通过它来查找符号所在的目标文件。注意！它也是以Big-Endian格式储存的。

　　第三个成员StrTable是一个字符串表，它的长度m就是SectionHeader.Size的值减去（SymbolNum+1）*4。其结构很简单，就是一堆以‘\0’结尾的字符串（和COFF文件中的字符串表结构相同）。在有的系统中，它还可能是以“/\n”这两个字符结尾的字符串的集合。

　　很简单的一个结构，不过有两个成员的长度是不定的。怎么才能方便地从Lib中读出这些数据，留给大家自己想吧！下面我只给出一个进行Little-Endian与Big-Endian互转的函数。

　　inline void convert(void * p // 要转换的数据的指针

　　,size_tsize = 4 // 数据的长度，long为4，short为2

　　) {

　　char * buf=(char*)p;

　　char temp;

　　for ( size_t i=0;i<size/2;i++ ) {

　　temp=buf[i];

　　buf[i]=buf[size-i-1];

　　buf[size-i-1]=temp;

　　}

　　}

Second Sec

　　第二节

　　这一节与第一节很相似！它通常也就是Lib文件的第二个节。它的名字也是“/”（注意：文件中第一个叫“/”的节是第一节，第二个就是第二节）。不过它的结构与第一节有些不同，如下：

　　typedef struct {

　　unsigned long ObjNum; // Obj Sec的数量

　　unsigned long ObjOffset[x]; // 每一个Obj Sec的偏移

　　unsigned long SymbolNum; // 库中符号的数量

　　unsigned short SymbolIdx[n]; // 符号在ObjOffset表中的索引

　　char StrTable[m]; // 符号名称字符串表

　　}SecondSec;

　　第一个成员ObjNum是库中Obj Sec的数量。

　　第二个成员ObjOffset是一个偏移表，它记录了库中所有Obj Sec的偏移。这个表的记录数x就是ObjNum。

　　第三个成员SymbolNum与First Sec中的SymbolNum意义相同。

　　第四个成员SymbolIdx变成了一个索引，它记录了相应名称字符串在ObjOffset这个表中的位置，我们要通过两次索引才能找到我们所要符号的Obj Sec位置。它的项目数n为SymbolNum。但请注意，这个索引是unsigned short型，不再是unsigned long型。

　　第五个成员StrTable结构与First Sec中的一样。不过，它的长度m为SectionHeader.Size的值减去((ObjNum+1)*4+(SymbolNum+2)*2)。

　　值得注意的是，这里的所有数据都是Little-Endian格式的。千万不要弄错了！Longname Sec

　　这个小节就是一个字符串表，它的名称为“//”，其结构同FirstSec.StrTable。这里就不多说了。

　　Obj Sec

　　这一节中的数据就是COFF文件的原始数据，把它读出来存成文件，就是一个COFF文件。它的格式请参考《COFF格式》一文。

　　要指出的是它的命名方式有些特殊。如果Obj文件的名称少于16个字符，它就会被保存在SectionHeader的Name成员中，以‘/’字符结尾。如果无法保存在Name成员中，则Name成员的第一个字符就为‘/’，之后再跟上这个名称在Longname Sec中的偏移。

　　例如：

　　!<arch>\n

　　……

　　LongName Sec:

　　This_Is_Long_Name0001\0

　　This_Is_Long_Name0002\0

　　……

　　Obj Sec1:

　　Name[16]：“shortname/”

　　……

　　Obj Sec2:

　　Name[16]：“/0” // 这里使用了第一个长文件名This_Is_Long_Name0001

　　……

　　Obj Sec3:

　　Name[16]：“/22” // 这里使用了第二个长文件名This_Is_Long_Name0002

lib文件与dll

　　(1)lib是编译时需要的，dll是运行时需要的。

　　如果要完成源代码的编译，有lib就够了。

　　如果也使动态连接的程序运行起来，有dll就够了。

　　在开发和调试阶段，当然最好都有。

　　(2)一般的动态库程序有lib文件和dll文件。lib文件是必须在编译期就连接到应用程序中的，而dll文件是运行期才会被调用的。如果有dll文件，那么对应的lib文件一般是一些索引信息，具体的实现在dll文件中。如果只有lib文件，那么这个lib文件是静态编译出来的，索引和实现都在其中。静态编译的lib文件有好处：给用户安装时就不需要再挂动态库了。但也有缺点，就是导致应用程序比较大，而且失去了动态库的灵活性，在版本升级时，同时要发布新的应用程序才行。

　　(3)在动态库的情况下，有两个文件，一个是引入库（.LIB）文件，一个是DLL文件，引入库文件包含被DLL导出的函数的名称和位置，DLL包含实际的函数和数据，应用程序使用LIB文件链接到所需要使用的DLL文件，库中的函数和数据并不复制到可执行文件中，因此在应用程序的可执行文件中，存放的不是被调用的函数代码，而是DLL中所要调用的函数的内存地址，这样当一个或多个应用程序运行是再把程序代码和被调用的函数代码链接起来，从而节省了内存资源。从上面的说明可以看出，DLL文件必须随应用程序一起发行，否则应用程序将会产生错误。

加载LIB文件方法

直接加入

　　在VC中打开File View一页，选中工程名，单击鼠标右键，然后选中"Add Files to Project"菜单，在弹出的文件对话框中选中要加入DLL的LIB文件即可。

设置工程的 Project Setting

　　打开工程的 Project Settings菜单，选中Link，然后在Object/library modules下的文本框中输入DLL的LIB文件。

通过程序代码

　　加入预编译指令#pragma comment (lib,"*.lib")，这种方法优点是可以利用条件预编译指令链接不同版本的LIB文件。因为，在Debug方式下，产生的LIB文件是Debug版本，如Regd.lib；在Release方式下，产生的LIB文件是Release版本，如Regr.lib。

　　当应用程序对DLL的LIB文件加载后，还需要把DLL对应的头文件（*.h）包含到其中，在这个头文件中给出了DLL中定义的函数原型，然后声明。