静态链接库和动态链接库的区别(大地小神之个人收藏).docxVIP

Linux下静态链接库与动态链接库的区别一例子详解文件目录树如下: 1. libtest/ 2. |-- myjob.c 3. |-- myjob.h 4. |-- test.c 静态库A.做成静态库 libmyjob.a 1. $ gcc -c myjob.c -o myjob.o 2. $ ar crs libmyjob.a myjob.oB.链接 1. $ gcc test.o libmyjob.a -o test C.引用库情况（无所要信息） 1. $ ldd test 2. linux-gate.so.1 = (0xffffe000) 3. libc.so.6 = /lib/libc.so.6 (0xb7e29000) 4. /lib/ld-linux.so.2 (0xb7f6e000) 动态库A.做成动态库 libmyjob.so 1. $ gcc -Wall –fPIC -c myjob.c -o myjob.o 2. $ gcc -shared -o libmyjob.so myjob.o -shared: 该选项指定生成动态连接库（让连接器生成T类型的导出符号表，有时候也生成弱连接W类型的导出符号），不用该标志外部程序无法连接。相当于一个可执行文件。-fPIC：表示编译为位置独立的代码，不用此选项的话编译后的代码是位置相关的所以动态载入时是通过代码拷贝的方式来满足不同进程的需要，而不能达到真正代码段共享的目的。-L.：表示要连接的库在当前目录中。LD_LIBRARY_PATH：这个环境变量指示动态连接器可以装载动态库的路径。B.链接链接方法I，拷贝到系统库里再链接，让gcc自己查找： 1. $ sudo cp libmyjob.so /usr/lib 2. $ gcc -o test test.o -lmyjob 这里我们可以看到了 -lmyjob 选项，-l[lib_name] 指定库名，他会主动搜索。lib[lib_name].so这个搜索的路径可以通过 gcc --print-search-dirs来查找。链接方法II，手动指定库路径 1. $ gcc -o test test.o -lmyjob -B /path/to/lib-B选项就添加 /path/to/lib 到gcc搜索的路径之中。这样链接没有问题但是方法II中手动链接好的程序在执行时候仍旧需要指定库路径（链接和执行是分开的）。需要添加系统变量 LD_LIBRARY_PATH : 1. $ export LD_LIBRARY_PATH=/path/to/lib 这个时候再来检测一下test程序的库链接状况(方法I情况) 1. $ ldd test 2. linux-gate.so.1 = (0xffffe000) 3. libmyjob.so = /usr/lib/libmyjob.so (0xb7f58000) 4. libc.so.6 = /lib/libc.so.6 (0xb7e28000) 5. /lib/ld-linux.so.2 (0xb7f6f000) 是不是比静态链接的程序多了一个 libmyjob.so? 这就是静态与动态的最大区别，静态情况下，它把库直接加载到程序里，而在动态链接的时候，它只是保留接口，将动态库与程序代码独立。这样就可以提高代码的可复用度，和降低程序的耦合度。另外，运行时，要保证主程序能找到动态库，所以动态库一般发布到系统目录中，要么就在跟主程序相对很固定的路径里，这样不管主程序在本机何时何地跑，都能找得到动态库。而静态库只作用于链接时，运行主程序时静态库文件没存在意义了。二静态库和动态库的区别1. 静态函数库这类库的名字一般是libxxx.a；利用静态函数库编译成的文件比较大，因为整个函数库的所有数据都会被整合进目标代码中，他的优点就显而易见了，即编译后的执行程序不需要外部的函数库支持，因为所有使用的函数都已经被编译进去了。当然这也会成为他的缺点，因为如果静态函数库改变了，那么你的程序必须重新编译。2. 动态函数库这类库的名字一般是libxxx.so;相对于静态函数库，动态函数库在编译的时候并没有被编译进目标代码中，你的程序执行到相关函数时才调用该函数库里的相应函数，因此动态函数库所产生的可执行文件比较小。由于函数库没有被整合进你的程序，而是程序运行时动态的申请并调用，所以程序的运行环境中必须提供相应的库。动态函数库的改变并不影响你的程序，所以动态函数库的升级比较方便。linux静态函数库的创建和使用A.例程str_out.h str_out.c main.c/* str_ou