符号重定位

讲动态链接之前，得先说说符号重定位。

为定安等地区用户提供了全套网页设计制作服务，及定安网站建设行业解决方案。主营业务为做网站、网站设计、定安网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！

c/c++ 程序的编译是以文件为单位进行的，因此每个 c/cpp 文件也叫作一个编译单元(translation unit), 源文件先是被编译成一个个目标文件, 再由链接器把这些目标文件组合成一个可执行文件或库，链接的过程，其核心工作是解决模块间各种符号(变量，函数)相互引用的问题，对符号的引用本质是对其 在内存中具体地址的引用，因此确定符号地址是编译，链接，加载过程中一项不可缺少的工作，这就是所谓的符号重定位。本质上来说，符号重定位要解决的是当前编译单元如何访问「外部」符号这个问题。

因为编译是以源文件为单位进行的，编译器此时并没有一个全局的视野，因此对一个编译单元内的符号它是无力确定其最终地址的，而对于可执行文件来说， 在现代操作系统上，程序加载运行的地址是固定或可以预期的，因此在链接时，链接器可以直接计算分配该文件内各种段的绝对或相对地址。所以对于可执行文件来说，符号重定位是在链接时完成的(如果可执行文件引用了动态库里的函数，则情况稍有不同)。但对于动态链接库来说，因为动态库的加载是在运行时，且加载的地址不固定，因此没法事先确定该模块的起始地址，所以对动态库的符号重定位，只能推迟。

符号重定位既指在当前目标文件内进行重定位，也包括在不同目标文件，甚至不同模块间进行重定位，这里面有什么不同吗？如果是同一个目标文件内，或者 在同一个模块内，链接后，各个符号的相对地址就已经确定了，看起来似乎不用非得要知道最后的绝对地址才能引用这些符号，这说起来好像也有道理，但事实不是 这样，x86 上 mov 之类访问程序中数据段的指令，它要求操作数是绝对地址，而对于函数调用，虽然是以相对地址进行调用，但计算相对地址也只限于在当前目标文件内进行，跨目标 文件跨模块间的调用，编译期也是做不到的，只能等链接时或加载时才能进行相对地址的计算，因此重定位这个过程是不能缺少的，事实上目前来说，对于动态链接 即使是当前目标文件内，如果是全局非静态函数，那么它也是需要进行重定位的。

注：

动态链接，在可执行文件装载时或运行时，由操作系统的装载程序加载库。大多数操作系统将解析外部引用（比如库）作为加载过程的一部分。在这些系统上，可执行文件包含一个叫做import directory的表，该表的每一项包含一个库的名字。根据表中记录的名字，装载程序在硬盘上搜索需要的库，然后将其加载到内存中预先不确定的位置，之后根据加载库后确定的库的地址更新可执行程序。可执行程序根据更新后的库信息调用库中的函数或引用库中的数据。这种类型的动态加载成为装载时加载 ，被包括Windows和Linux的大多数系统采用。装载程序在加载应用软件时要完成的最复杂的工作之一就是加载时链接。

其他操作系统可能在运行时解析引用。在这些系统上，可执行程序调用操作系统API，将库的名字，函数在库中的编号和函数参数一同传递。操作系统负责立即解析然后代表应用调用合适的函数。这种动态链接叫做运行时链接 。因为每个调用都会有系统开销，运行时链接要慢得多，对应用的性能有负面影响。现代操作系统已经很少使用运行时链接。
　　可以动态链接的库，在Windows上是dynamic link library (DLL)，在UNIX或Linux上是Shared Library。库文件是预先编译链接好的可执行文件，存储在计算机的硬盘上。大多数情况下，同一时间多个应用可以使用一个库的同一份拷贝，操作系统不需要加载这个库的多个实例。
　　动态链接的最大缺点是可执行程序依赖分别存储的库文件才能正确执行。如果库文件被删除了，移动了，重命名了或者被替换为不兼容的版本了，那么可执行程序就可能工作不正常。这就是常说的DLL-hell。

g++编译参数：

-shared 该选项指定生成动态连接库（让连接器生成T类型的导出符号表，有时候也生成弱连接W类型的导出符号），不用该标志外部程序无法连接。相当于一个可执行文件。

-fPIC：表示编译为位置独立的代码，不用此选项的话编译后的代码是位置相关的所以动态载入时是通过代码拷贝的方式来满足不同进程的需要，而不能达到真正代码段共享的目的。 

-L.：表示要连接的库在当前目录中 

-l Detour：编译器查找动态连接库时有隐含的命名规则，即在给出的名字前面加上lib，后面加上.so来确定库的名称

-I 项目中include包含的头文件寻找路径

文章标题：动态链接相关知识
转载来于：http://ybzwz.com/article/jpicph.html