零、问题
1. 为什么要用到库？
2. 我要用一个库，但是，尼玛命令行上该怎么写呢？或者说库文件如何使用？
3. Linux的库在那些地方？
4. 什么是静态库，什么是动态库，二者有啥区别？
5. 常见的与库管理相关的命令有哪些？
6. 什么是库？
一、库函数简介
C语言中有一些函数会执行一些标准任务，可以事先对这些函数进行编译，然后将他们放置在一些特殊的目标代码文件中，这些目标代码文件称为库。
库文件中的函数可以通过连接程序与应用程序进行链接，这样就不用在每次执行程序时都对这些通用的函数进行编译了。
标准的C函数库名称为libc，包含了诸如内存管理或者输入输出操作的基本函数。这些库放置在系统的公用目录下，如/usr/lib，系统中的任何用户都可以利用这些库函数，用户也可以自己建立库。
库的两种形式：静态库；共享库
预处理、编译和链接的过程
不使用动态库可能导致的后果
二、静态库
2.1 基本概念
静态库又称为文档文件（Archive File）。它是多个.o文件的集合。Linux中静态库文件的后缀为"a"。
静态库的代码在编译时就已经链接到应用程序中。
静态库中的各个成员（.o文件）没有特殊的存在格式，仅仅是一个.o文件的集合。
使用"ar"工具维护和管理静态库。
2.2 如何建立和使用静态库
下面是一个建立静态链接库的例子：
1. 编写源文件：
源码一：my_strcpy.c（实现一个strcpy的功能）
#include <stdio.h> #include <string.h> #include <stdlib.h> void my_strcpy(char *des, const char *src) { while (*des++ = *src++); }
源码二：my_strcmp.c（实现一个strcmp的功能）
#include <stdio.h> #include <string.h> #include <stdlib.h> int my_strcmp(const char *obj1, const char *obj2) { while (*obj1 && *obj2) { if(*obj1 - *obj2){ return (*obj1 - *obj2); } else { obj1++; obj2++; } } return 0; }
2. 生成.o文件
gcc -c my_strcpy.c my_strcmp.c
3. 建立静态链接库
ar rcs libmylib.a *.o这样，就在当前路径下面建立好了libmylib.a的静态库。
ar的三个参数中：
r - 代表将文件插入归档文件中；
c - 代表建立归档文件；
s - 代表若归档文件中包含了对象模式，可利用此参数建立备存文件的符号表。
lib和.a都是系统指定的静态库文件的固定格式，mylib才是静态库的名称，编译时，链接器会在标准路径（/usr/lib，/lib）或者用户指定的路径下去找.a的文件。
关于ar命令请移步这里：ar命令学习。
4. 测试静态链接库
编写测试代码：main.c
#include <stdio.h> #include <string.h> int main() { int res; char des[100] = {0}; const char *s1 = "hello linux."; const char *s2 = "hello world." my_strcpy(des, s1); printf("%s ", des); bzero(des, 0); my_strcpy(des, s2); printf("%s ", des); res = my_strcmp(s1, s2); if (res > 0) printf("s1 > s2 "); else if (res < 0) printf("s1 < s2 "); else printf("s1 = s2 "); return 0; }
gcc -o main main.c -static -L. –lmylib-static指定编译器链接静态库，-L.指定静态库的路径为当前路径，在gcc编译器中引用可搜索到的目录和库文件时需用（-l+库名），如在gcc中加入-lm可以在程序汇中链接标准算术库，加上-lpthread可以链接到linux标准线程库。
执行./main后的输出结果：
hello linux.
hello world.
s1 < s2
5. 小插曲
我执行上面这个命令报错了：
/usr/bin/ld: cannot find –lc
collect2: ld returned 1 exit status
解决办法：
Linux环境下gcc静态编译/usr/bin/ld: cannot find -lc错误原因及解决方法
原因：
一般出现这个问题的时候，Makefile中肯定有-static选项。这其实是静态链接时没有找到libc.a。
解决方案：
需要安装glibc-static.xxx.rpm，如glibc-static-2.12-1.107.el6_4.2.i686.rpm，或是yum install glibc-static
2.3 小结
使用静态库可以使程序不依赖于任何其他库而独立运行，但是会占用很多内存空间以及磁盘空间，而且如果库文件更新，则需重新编译源代码，使用起来不够灵活。
我们用ls –l main可以发现，可执行程序main的大小是500多KB，之所以会这么大就是因为我们在编译的时候指定了-static，这样编译时所有需要链接的库都是以静态库的形式链接的，而我们知道gcc默认会链接到标准C库，所以我们把标准C库的静态库版本也链接到了可执行程序里，导致程序占用的磁盘空间增大。
其实，编译的时候不需要加-static，直接用gcc -o main main.c -L. –lmylib，连接器会为我们链接指定的静态库以及标准C的共享库，这样编译之后，可执行程序只有7KB左右大小。
（指定了static的时候是所有的链接都是以静态库链接过去的，那么去掉了static之后是什么情况呢？）
三、基本概念
1.1 什么是库
在windows平台和linux平台下都大量存在着库。
本质上来说库是一种可执行代码的二进制形式，可以被操作系统载入内存执行。
由于windows和linux的平台不同（主要是编译器、汇编器和连接器的不同），因此二者库的二进制是不兼容的。
本文仅限于介绍linux下的库。
1.2 库的种类
linux下的库有两种：静态库和共享库（动态库）。
二者的不同点在于代码被载入的时刻不同。
静态库的代码在编译过程中已经被载入可执行程序，因此体积较大。
共享库的代码是在可执行程序运行时才载入内存的，在编译过程中仅简单的引用，因此代码体积较小。
1.3 库存在的意义
库是别人写好的现有的，成熟的，可以复用的代码，你可以使用但要记得遵守许可协议。
现实中每个程序都要依赖很多基础的底层库，不可能每个人的代码都从零开始，因此库的存在意义非同寻常。
共享库的好处是，不同的应用程序如果调用相同的库，那么在内存里只需要有一份该共享库的实例。
1.4 库文件是如何产生的在linux下
静态库的后缀是.a，它的产生分两步
Step 1：由源文件编译生成一堆.o，每个.o里都包含这个编译单元的符号表
Step 2：ar命令将很多.o转换成.a，成为静态库
动态库的后缀是.so，它由gcc加特定参数编译产生。
具体方法参见后文实例。
1.5 库文件是如何命名的，有没有什么规范
在linux下，库文件一般放在/usr/lib和/lib下，
静态库的名字一般为libxxxx.a，其中xxxx是该lib的名称
动态库的名字一般为libxxxx.so.major.minor，xxxx是该lib的名称，major是主版本号， minor是副版本号
1.6 如何知道一个可执行程序依赖哪些库
ldd命令可以查看一个可执行程序依赖的共享库。
例如# ldd /bin/ln
这里好像只能看共享库，静态库看不到了，网上查到了一个说法是：只能查看可执行文件链接的动态库，静态库和obj是不可能查到的。因为他已经成为了一部分。好像有道理。
1.7 可执行程序在执行的时候如何定位共享库文件
当系统加载可执行代码时候，能够知道其所依赖的库的名字，但是还需要知道绝对路径。
此时就需要系统动态载入器(dynamic linker/loader)，这是个啥？
对于elf格式的可执行程序，是由ld-linux.so*来完成的，它先后搜索elf文件的DT_RPATH段—环境变量LD_LIBRARY_PATH—/etc/ld.so.cache文件列表—/lib/，/usr/lib目录找到库文件后将其载入内存
如：export LD_LIBRARY_PATH='pwd'
将当前文件目录添加为共享目录
1.8 在新安装一个库之后如何让系统能够找到他
如果安装在/lib或者/usr/lib下，那么ld默认能够找到，无需其他操作。
如果安装在其他目录，需要将其添加到/etc/ld.so.cache文件中，步骤如下
1. 编辑/etc/ld.so.conf文件，加入库文件所在目录的路径
2. 运行ldconfig，该命令会重建/etc/ld.so.cache文件
四、用gcc生成静态和动态链接库的示例
我们通常把一些公用函数制作成函数库，供其它程序使用。函数库分为静态库和动态库两种。
静态库在程序编译时会被连接到目标代码中，程序运行时将不再需要该静态库。
动态库在程序编译时并不会被连接到目标代码中，而是在程序运行是才被载入，因此在程序运行时还需要动态库存在。
4.1 准备好测试代码add.h、add.c和test.c
add.h(见程序1)为该函数库的头文件。
add.c(见程序2)是函数库的源程序，其中包含公用函数add，该函数将在屏幕上输出"uplooking"。
test.c(见程序3)为测试库文件的主程序，在主程序中调用了公用函数add。
程序1: add.h
#ifndef __ADD_H__ #define __ADD_H__ #include <stdio.h> int add(int x, int y); #endif/*__ADD_H__*/
程序2：add.c
#include "add.h" int add(int x, int y) { printf("Hello Uplooking... "); return x + y; }
程序3：test.c
#include "add.h" int main(void) { int x = 15; int y = 3; printf("x + y = %d ", add(x, y)); return 0; }
4.2 问题的提出
注意：这个时候，我们编译好的add.o是无法通过gcc –o 编译的，这个道理非常简单，add.c是一个没有main函数的.c程序，因此不够成一个完整的程序，如果使用gcc –o 编译并连接它，GCC将报错。无论静态库，还是动态库，都是由.o文件创建的。因此，我们必须将源程序add.c通过gcc先编译成.o文件。
这个时候我们有三种思路：
1） 通过编译多个源文件，直接将目标代码合成一个.o文件。
2） 通过创建静态链接库libadd.a，使得main函数调用add函数时可调用静态链接库。
3） 通过创建动态链接库libadd.so，使得main函数调用add函数时可调用动态链接库。
4.3 思路一：编译多个源文件
在系统提示符下键入以下命令得到hello.o文件。
[root@deng test]# gcc -c add.c -o add.o为什么不使用gcc –o tes test.c 这个道理我们之前已经说了，使用-c是什么意思呢？这涉及到gcc编译选项的常识（好吧，我不知道这个常识）。
我们通常使用的gcc –o 是将.c源文件编译成为一个可执行的二进制代码（-o选项其实是制定输出文件文件名，如果不加-c选项，gcc默认会编译连接生成可执行文件，文件的名称有-o选项指定），这包括调用作为GCC内的一部分真正的C编译器（ccl），以及调用GNU C编译器的输出中实际可执行代码的外部GNU汇编器（as）和连接器工具（ld）。而gcc –c是使用GNU汇编器将源文件转化为目标代码之后就结束，在这种情况下,只调用了C编译器（ccl）和汇编器（as），而连接器(ld)并没有被执行，所以输出的目标文件不会包含作为Linux程序在被装载和执行时所必须的包含信息，但它可以在以后被连接到一个程序。
我们运行ls命令看看是否生存了test.o文件。
# ls
add.c add.h add.o test.c
在ls命令结果中，我们看到add.o文件，本步操作完成。
同理编译test
[root@deng test]# gcc -c test.c -o test.o
将两个文件链接成一个.o文件。
[root@deng test]# gcc test.o add.o -o test
4.4 思路二：静态链接库
下面我们先来看看如何创建静态库，以及使用它。
静态库文件名的命名规范是以lib为前缀，紧接着跟静态库名，扩展名为.a。例如：我们将创建的静态库名为add，则静态库文件名就是libadd.a。在创建和使用静态库时，需要注意这点。创建静态库用ar命令。
在系统提示符下键入以下命令将创建静态库文件libadd.a。
ls命令结果中有libadd.a。
静态库制作完了，如何使用它内部的函数呢？只需要在使用到这些公用函数的源程序中包含这些公用函数的原型声明，然后在用gcc命令生成目标文件时指明静态库名，gcc将会从静态库中将公用函数连接到目标文件中。注意，gcc会在静态库名前加上前缀lib，然后追加扩展名.a得到的静态库文件名来查找静态库文件,因此，我们在写需要连接的库时，只写名字就可以，如libadd.a的库，只写:-ladd
在程序3:test.c中，我们包含了静态库的头文件add.h，然后在主程序main中直接调用公用函数add。下面先生成目标程序test，然后运行test程序看看结果如何。
我们删除静态库文件试试公用函数add是否真的连接到目标文件 add中了。
程序照常运行，静态库中的公用函数已经连接到目标文件中了。
静态链接库的一个缺点是，如果我们同时运行了许多程序，并且它们使用了同一个库函数，这样，在内存中会大量拷贝同一库函数。这样，就会浪费很多珍贵的内存和存储空间。使用了共享链接库的Linux就可以避免这个问题。
共享函数库和静态函数在同一个地方，只是后缀有所不同。比如，在一个典型的Linux系统，标准的共享数序函数库是/usr/lib/libm.so。
当一个程序使用共享函数库时，在连接阶段并不把函数代码连接进来，而只是链接函数的一个引用。当最终的函数导入内存开始真正执行时，函数引用被解析，共享函数库的代码才真正导入到内存中。这样，共享链接库的函数就可以被许多程序同时共享，并且只需存储一次就可以了。共享函数库的另一个优点是，它可以独立更新，与调用它的函数毫不影响。
2.5 思路三、动态链接库（共享函数库）
我们继续看看如何在Linux中创建动态库。我们还是从.o文件开始。
动态库文件名命名规范和静态库文件名命名规范类似，也是在动态库名增加前缀lib，但其文件扩展名为.so。例如：我们将创建的动态库名为add，则动态库文件名就是libadd.so。用gcc来创建动态库。
在系统提示符下键入以下命令得到动态库文件libadd.so。
[root@deng test]# gcc --shared -fPIC -o libadd.so add.c [root@deng test]# ls add.c add.h bak libadd.so test.c [root@deng test]#
"PIC"命令行标记告诉GCC产生的代码不要包含对函数和变量具体内存位置的引用，这是因为现在还无法知道使用该消息代码的应用程序会将它连接到哪一段内存地址空间。这样编译出的add.c可以被用于建立共享链接库。建立共享链接库只需要用GCC的"-shared"标记即可。
调用动态链接库编译目标文件。
在程序中使用动态库和使用静态库完全一样，也是在使用到这些公用函数的源程序中包含这些公用函数的原型声明，然后在用gcc命令生成目标文件时指明动态库名进行编译。我们先运行gcc命令生成目标文件，再运行它看看结果。
如果直接用如下方法进行编译，并连接：
[root@deng test]# gcc test.c -o test -I. -L. -ladd
（使用”-ladd”标记来告诉GCC驱动程序在连接阶段引用共享函数库libadd.so。”-L.”标记告诉GCC函数库可能位于当前目录。否则GNU连接器会查找标准系统函数目录:它先后搜索
1.elf文件的 DT_RPATH段
2.环境变量LD_LIBRARY_PATH
3./etc/ld.so.cache文件列表
4./lib/,/usr/lib目录找到库文件后将其载入内存,但是我们生成的共享库在当前文件夹下，并没有加到上述的4个路径的任何一个中，因此，执行后会出现错误）
[root@deng test]# ./test
./test: error while loading shared libraries: libadd.so: cannot open shared object file: No such file or directory
[root@deng test]#
错误提示，找不到动态库文件libadd.so。程序在运行时，会在/usr/lib和/lib等目录中查找需要的动态库文件。若找到，则载入动态库，否则将提示类似上述错误而终止程序运行。有多种方法可以解决，
（1）我们将文件 libadd.so复制到目录/usr/lib中，再试试。
[root@deng test]# cp libadd.so /usr/lib cp：是否覆盖"/usr/lib/libadd.so"？ y [root@deng test]# ldconfig [root@deng test]# ./test Hello Uplooking... x + y = 18 [root@deng test]#
（2）既然连接器会搜寻LD_LIBRARY_PATH所指定的目录，那么我们可以将这个环境变量设置成当前目录：
先执行：
[root@deng test]# export LD_LIBRARY_PATH=$(pwd) [root@deng test]# ./test Hello Uplooking... x + y = 18 [root@deng test]#
注: 当用户在某个目录下面创建或拷贝了一个动态链接库,若想使其被系统共享,可以执行一下"ldconfig 目录名"这个命令。此命令的功能在于让ldconfig将指定目录下的动态链接库被系统共享起来，意即：在缓存文件/etc/ld.so.cache中追加进指定目录下的共享库.本例让系统共享了/usr/zhsoft/lib目录下的动态链接库。该命令会重建/etc/ld.so.cache文件。
下面的这个错误我没有遇到，不过也记录下，给遇到的人：
这步后我没有成功,报错内容如下：/hello: error while loading shared libraries: /usr/lib/libmyhello.so: cannot restore segment prot after reloc: Permission denied
google了一下，发现是SELinux搞的鬼，解决办法有两个：
第一个：
chcon -t texrel_shlib_t /usr/lib/libmyhello.so (chcon -t texrel_shlib_t "你不能share的库的绝对路径")
第二个：
#vi /etc/sysconfig/selinux file 或者用 #gedit /etc/sysconfig/selinux file 修改SELINUX=disabled 重启
这也进一步说明了动态库在程序运行时是需要的。
可以查看程序执行时调用动态库的过程：
# ldd test
执行 test,可以看到它是如何调用动态库中的函数的。
[root@deng test]# ldd test linux-vdso.so.1 => (0x00007fffabdff000) libadd.so => /tmp/test/libadd.so (0x00007fecf17ce000) libc.so.6 => /lib64/libc.so.6 (0x000000333f200000) /lib64/ld-linux-x86-64.so.2 (0x000000333ea00000)
我们回过头看看，发现使用静态库和使用动态库编译成目标程序使用的gcc命令完全一样，那当静态库和动态库同名时，gcc命令会使用哪个库文件呢？我刚刚也发现了有这个问题。抱着对问题必究到底的心情，来试试看。
先删除除.c和.h外的所有文件，恢复成我们刚刚编辑完举例程序状态。
# rm -f hello hello.o /usr/lib/libmyhello.so # ls hello.c hello.h main.c
在来创建静态库文件libmyhello.a和动态库文件libmyhello.so。
# gcc -c hello.c # ar rcs libmyhello.a hello.o # gcc -shared -fPCI -o libmyhello.so hello.o # ls hello.c hello.h hello.o libmyhello.a libmyhello.so main.c
通过上述最后一条ls命令，可以发现静态库文件libmyhello.a和动态库文件libmyhello.so都已经生成，并都在当前目录中。然后，我们运行gcc命令来使用函数库myhello生成目标文件hello，并运行程序 hello。
# gcc -o hello main.c -L. -lmyhello # ./hello ./hello: error while loading shared libraries: libmyhello.so: cannot open shared object file: No such file or directory
从程序hello运行的结果中很容易知道，当静态库和动态库同名时， gcc命令将优先使用动态库。
Note:
编译参数解析
最主要的是GCC命令行的一个选项:
-shared 该选项指定生成动态连接库（让连接器生成T类型的导出符号表，有时候也生成弱连接W类型的导出符号），不用该标志外部程序无法连接。相当于一个可执行文件
l -fPIC：表示编译为位置独立的代码，不用此选项的话编译后的代码是位置相关的所以动态载入时是通过代码拷贝的方式来满足不同进程的需要，而不能达到真正代码段共享的目的。
l -L.：表示要连接的库在当前目录中
l -ltest：编译器查找动态连接库时有隐含的命名规则，即在给出的名字前面加上lib，后面加上.so来确定库的名称
l LD_LIBRARY_PATH：这个环境变量指示动态连接器可以装载动态库的路径。
l 当然如果有root权限的话，可以修改/etc/ld.so.conf文件，然后调用 /sbin/ldconfig来达到同样的目的，不过如果没有root权限，那么只能采用输出LD_LIBRARY_PATH的方法了。
调用动态库的时候有几个问题会经常碰到，有时，明明已经将库的头文件所在目录 通过 “-I” include进来了，库所在文件通过 “-L”参数引导，并指定了“-l”的库名，但通过ldd命令察看时，就是死活找不到你指定链接的so文件，这时你要作的就是通过修改 LD_LIBRARY_PATH或者/etc/ld.so.conf文件来指定动态库的目录。通常这样做就可以解决库无法链接的问题了。
静态库链接时搜索路径顺序：
1. ld会去找GCC命令中的参数-L
2. 再找gcc的环境变量LIBRARY_PATH
3. 再找内定目录 /lib /usr/lib /usr/local/lib 这是当初compile gcc时写在程序内的
动态链接时、执行时搜索路径顺序:
1. 编译目标代码时指定的动态库搜索路径；
2. 环境变量LD_LIBRARY_PATH指定的动态库搜索路径；
3. 配置文件/etc/ld.so.conf中指定的动态库搜索路径；
4. 默认的动态库搜索路径/lib；
5. 默认的动态库搜索路径/usr/lib。
有关环境变量：
LIBRARY_PATH环境变量：指定程序静态链接库文件搜索路径
LD_LIBRARY_PATH环境变量：指定程序动态链接库文件搜索路
五、总结
创建并使用静态库
第一步：编辑源文件，test.h test.c main.c。其中main.c文件中包含main函数，作为程序入口；test.c中包含main函数中需要用到的函数。
vi test.h test.c main.c
第二步：将test.c编译成目标文件。
gcc -c test.c
如果test.c无误，就会得到test.o这个目标文件。
第三步：由.o文件创建静态库。
ar rcs libtest.a test.o
第四步：在程序中使用静态库。（顺序问题）
gcc -o main main.c -L. -ltest
因为是静态编译，生成的执行文件可以独立于.a文件运行。
第五步：执行。
./main
创建并使用动态库
第一步：编辑源文件，test.h test.c main.c。其中main.c文件中包含main函数，作为程序入口；test.c中包含main函数中需要用到的函数。
vi test.h test.c main.c
第二步：将test.c编译成目标文件。
gcc -c test.c
前面两步与创建静态库一致。
第三步：由.o文件创建动态库文件。
gcc -shared -fPIC -o libtest.so test.o
第四步：在程序中使用动态库。
gcc -o main main.c -L. -ltest
当静态库和动态库同名时，gcc命令将优先使用动态库。
第五步：执行。
LD_LIBRARY_PATH=. ./main
示例五 查看静态库中的文件
[root@node56 lib]# ar -t libhycu.a
base64.c.o
binbuf.c.o
cache.c.o
chunk.c.o
codec_a.c.o
六、静、动态链接库的区别总结
区别1：在目标文件链接成可执行文件阶段，库函数(库函数本身有一个代码段)链接进可执行文件（代码段）中，占了很大的内存空间。而使用动态库时，只是在链接时做了一个printf的标记，当可执行程序运行时才会加载这段printf（从库路径中加载动态链接库.so文件），这样就节省了可执行程序的空间，只有在运行这段很短的时间会占用可执行程序的空间。
可以做个测试，写一个输出hello world的小程序，一般是Linux下gcc中是默认是使用动态库的，可以看到可执行程序a.out的大小只有7千多k，而使用静态库，链接后生成可执行程序时把printf也链接到了可执行程序中，这时候可执行程序就有700多K了。
区别2：使用动态库对库的依赖性太强，一般发布的话需要库文件（库文件要放在相应的库路径中）也发布。、
静态链接库对库的依赖性不会有那么强。静态库就像房车，出门旅游不用依赖住房，但是房车占空间；动态库就像小车，出门旅游依赖要住酒店，但是小车省空间。
实际上使用动态库在运行的时候加载printf也会占用可执行程序，在运行时占用可执行程序的空间其实是跟静态库是一样的。
但是试想：一个可执行程序a.out中有多个文件（如a应用程序,b应用程序,c文件程序），a,b,c都需要调用printf。
使用静态库时，链接时就链接了三份printf，运行时就加载三份printf，产生多分副本，白白浪费内存。而使用动态库时，链接时，只是将printf的标记链接进了可执行程序a,out，运行时printf只用加载一份，a调用时就是调用这一份printf，b调用时也是调用这一份printf。-------这才是动态库相对于静态库真正的优势！
总结：静态库：1.链接时将程序放进进可执行程序
2.会产生多分副本
3.不依赖程序运行
动态库：1.程序运行时，加载时才去动态库找函数
2.多进程共享
3.依赖程序运行
todo：
http://developer.51cto.com/art/201505/476344_all.htm