库

windows平台和linux平台下都存在着大量的库
本质上说库是一种可执行的二进制代码(但不可以独立执行)，可以被操作系统载入内存执行
但是由于windows和linux的平台不同(编译器，汇编器，链接器不同)，所以两者库的二进制是不同的

Makefile中的option说明
以下介绍linux下的库：

linux下库有两种：静态库和共享库(动态库)
区别：

• 静态库

代码在编译过程中已经被载入可执行程序，因此生成的可执行程序体积较大。
静态用.a为后缀， 例如： libhello.a

静态库链接时搜索路径的顺序：

1. ld会去找gcc/g++命令中的参数-L
2. 再找gcc环境变量LIBRARY_PATH (指定静态链接库文件搜索路径)

• 动态库(共享库 share object)
  与静态库相比，两者的载入时间不同
  代码是在可执行程序运行时才载入内存的，在编译过程中仅简单的引用，因此生成的可执行程序代码体积较小
  动态通常用.so为后缀， 例如：libhello.so
  共享库(动态库)的好处是:不同的应用程序如果调用相同的库，那么在内存里只需要有一份该共享库的实例
  为了在同一系统中使用不同版本的库，可以在库文件名后加上版本号为后缀,例如： libhello.so.1.0,由于程序连接默认以.so为文件后缀名。所以为了使用这些库，通常使用建立符号连接的方式。

ln -s 源文件 目标文件 类似于windows下超链接，在目标文件目录下软链接源文件

  ln -s libhello.so.1.0 libhello.so.1 
  ln -s libhello.so.1 libhello.so

执行文件执行时搜索动态库的搜索路径顺序：

1. 编译目标代码时指定的动态搜索路径
2. 再找环境变量LD_LIBRARY_PATH （指定动态库搜索路径） 如：
   export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:data/home/Alex/lib
3. 配置文件 /etc/ld.so.conf 中指定的动态库搜索路径
4. 默认的动态库索搜路径 /lib
5. 默认的动态库搜索路径 /usr/lib
   对于 elf 格式的可执行程序，是由 ld-linux.so* 来完成的，它先后搜索 elf 文件的 DT_RPATH 段–>环境变量LD_LIBRARY_PATH—->/etc/ld.so.cache 文件列表–> /lib/,/usr/lib 目录找到库文件后将其载入内存
   如： export LD_LIBRARY_PATH=’pwd’
   将当前文件目录添加为共享目录

1. 生成 .a或 .so库

#include "hello.h"  
void sayhello()  {
    	printf("hello,world ");	}

1.1 动态库

在 linux 下，库文件一般放在/usr/lib和/lib下

命名规范：

1. 静态库的名字一般为libxxxx.a，其中 xxxx 是该lib的名称
2. 由于可能存在多个版本，通常在文件名后加上版本号座位后缀(动态库的名字一般为libxxxx.so.major.minor，xxxx是该lib的名称，major是主版本号，minor是副版本号)

1.1.1 用gcc来生成动态库

1. 首先使用gcc编译该文件，在编译时可以使用任何合法的编译参数，例如-g加入调试代码：

gcc -c hello.c -o hello.o

2. 在用gcc来生成动态库，由于可能存在多个版本，因此通常制定版本号：

gcc -shared -fPIC -o libhello.so.1.0 hello.o

3. 在程序中使用动态库
   Linux下的库文件在命名时有一个约定，那就是应该以lib三个字母开头，由于所有的库文件都遵循了同样的规范，因此在用-l选项指定链接的库文件名时可以省去lib三个字母，也就是说GCC在对-lhello进行处理时，会自动去链接名为libhello.so的文件

gcc -o main main.c -L. -lhello

当静态库和动态库同名时， gcc命令将优先使用动态库

gcc/g++中关于库的参数：
-shared :指定生成动态连接库
-fPIC :表示编译为位置独立的代码（地址无关），不选用此选项的话，编译后的代码是位置相关的，所以动态载入时，时通过代码拷贝的方式来满足不同进程的需要，因而不能达到真正的代码段共享的目的
-L :指定链接库的路径，-L表示链接库在当前目录之中 链接时的库路径，生成的可执行文件在运行时库的路径由LD_LIBRARY_PATH环境变量指定
-ltest :指定链接库的名称 test, 编译器查找动态链接库时有隐含的命名规则（在test前加上lib，在其后加上.so来确定库的名称）
-WI，-rpath:记录以so文件的路径信息
LIBRARY_PATH环境变量：指定程序静态链接库文件搜索路径

LD_LIBRARY_PATH: 环境变量，指示动态连接器可以装载动态库的文件搜索路径；

1. 如果有root权限，可以修改/etc/ld.so.conf文件，然后调用/sbin/ldconfig来达到同样的目的
2. 不过如果没有root权限，只能修改LD_LIBRARY_PATH环节变量的方法
3. 有时，明明已经将库的头文件所在目录 通过 “-I” include进来了，库所在文件通过 “-L”参数引导，并指定了“-l”的库名，但通过ldd命令察看时，就是死活找不到你指定链接的so文件，这时你要作的就是通过修改 LD_LIBRARY_PATH或者/etc/ld.so.conf文件来指定动态库的目录。通常这样做就可以解决库无法链接的问题了

可执行程序在执行时如何定位共享库文件：

1. 当系统加载可执行代码(库文件)的时候，能够知道其所依赖的库的名字，但是还需要知道绝对路径，此时就需要系统动态载入器（dynamic linker/loader）
2. 对于elf 格式的可执行程序，是由 ld-linux.so* 来完成的，它先后搜索 elf 文件的 DT_RPATH 段–>环境变量LD_LIBRARY_PATH—->/etc/ld.so.cache 文件列表–>/lib/,/usr/lib 目录找到库文件后将其载入内存

1.1.2 用ldd来查看可执行程序依赖那些动态库或者动态库依赖的动态库

ldd: list dynamic dependies

ldd /bin/lnlibc.so.6
 => /lib/libc.so.6 (0×40021000)/lib/ld-linux.so.2 
 => /lib/ld- linux.so.2 (0×40000000) 
   可以看到 ln 命令依赖于 libc 库和 ld-linux 库 

1.1.3 用nm来查看静态库或动态库中的函数名

nm: name 查看库中含有哪些函数，nm工具可以打印出库中的涉及到的所有符号，常见的有三类：

T类：是在库中定义的函数，用T表示，这是最常见的
U类：是在库中被调用，但并没有在库中定义(表明需要其他库支持)，用U表示
W类：是所谓的“弱态”符号，它们虽然在库中被定义，但是可能被其他库中的同名符号覆盖，用W表示

例子

假设开发者希望知道上文提到的hello库中是否引用了 printf():

grep: global regular expression printf

nm libhello.so | grep printf

可以发现printf是U类，说明printf是被引用，并没有在库中被定义，要正常使用hello库，必须依赖其他支持，我们继续使用ldd查看hello的依赖库：
在Mac OS X上otool -L equivalent of the Linux ldd

ldd libhello.so

2.1 静态库

静态库的名字一般为libxxx.a，xxx就是该lib的名称

2.1.1 用ar来生成静态库

1. 首先使用gcc编译该文件，在编译时可以使用任何合法的编译参数，例如-g加入调试代码：

gcc -c hello.c -o hello.o

2. 在用ar来生成静态库，ar为archive：

ar cqs libhello.a hello.o

c create
q quick append
r replace
s index list

3. 在程序中使用静态库

gcc -o main main.c -L. -lhello

因为是静态编译，生成的执行文件可以独立于.a文件运行

2.1.1 用ar工具来查看静态库中包含的.o文件（即源文件的构成）

查看静态库的构成：

ar -t libname.a		
ar -tv libname.a

3. 静态库和动态库同时存在时，gcc/g++默认链接的是动态库

可以使用下面的方法，给连接器ld传递参数，看是否链接动态库还是静态库。

-Wl,-Bstatic -llibname        //指定让gcc/g++链接静态库
使用:
gcc/g++ test.c -o test -Wl,-Bstatic -llibname -Wl,-Bdynamic -lm -lc 

-Wl,-Bdynamic -llibname       //指定让gcc/g++链接动态库
使用:
gcc/g++ test.c -o test -Wl,-Bdynamic -llibname

如果要完全静态加在，使用-static参数，即将所有的库以静态的方式链入可执行程序，这样生成的可执行程序，不再依赖任何库，同事出现的问题是，这样编译出来的程序非常大，占用空间

4. 库的依赖问题：

比如我们有一个基础库libbase.a,还有一个依赖libbase.a编译的库，叫做libchild.a；在我们编译程序时，一定要先-lchild再-lbase。 如果使用 -lbase -lchild，在编译时将出现一些函数undefined，而这些函数实际上已经在base中已经定义；
为什么会有库的依赖问题？
一、静态库解析符号引用：
链接器ld是如何使用静态库来解析引用的。在符号解析阶段，链接器从左至右，依次扫描可重定位目标文件（.o）和静态库（.a）。
在这个过程中，链接器将维持三个集合：
集合E：可重定位目标文件(.o文件)的集合。
集合U：未解析(未定义)的符号集，即符号表中UNDEF的符号。
集合D： 已定义的符号集。
初始情况下，E、U、D均为空。
1、对于每个输入文件f，如果是目标文件(.o)，则将f加入E，并用f中的符号表修改U、D(在文件f中定义实现的符号是D，在f中引用的符号是U)，然后继续下个文件。
2、如果f是一个静态库(.a)，那么链接器将尝试匹配U中未解析符号与静态库成员(静态库的成员就是.o文件)定义的符号。如果静态库中某个成员m(某个.o文件)定义了一个符号来解析U中引用，那么将m加入E中，
同时使用m的符号表，来更新U、D。对静态库中所有成员目标文件反复进行该过程，直至U和D不再发生变化。此时，静态库f中任何不包含在E中的成员目标文件都将丢弃，链接器将继续下一个文件。
3、当所有输入文件完成后，如果U非空，链接器则会报错，否则合并和重定位E中目标文件，构建出可执行文件。
到这里，为什么会有库的依赖问题已经得到解答：
因为libchild.a依赖于libbase.a，但是libbase.a在libchild.a的左边，导致libbase.a中的目标文件(.o)根本就没有被加载到E中，所以解决方法就是交换两者的顺序。当然也可以使用-lbase -lchild -lbase的方法。

5. 动态库升级问题：

比如我们有一个基础库libbase.a,还有一个依赖libbase.a编译的库，叫做libchild.a；在我们编译程序时，一定要先-lchild再-lbase。 如果使用 -lbase -lchild，在编译时将出现一些函数undefined，而这些函数实际上已经在base中已经定义；
为什么会有库的依赖问题？
一、静态库解析符号引用：
链接器ld是如何使用静态库来解析引用的。在符号解析阶段，链接器从左至右，依次扫描可重定位目标文件（.o）和静态库（.a）。
在这个过程中，链接器将维持三个集合：
集合E：可重定位目标文件(.o文件)的集合。
集合U：未解析(未定义)的符号集，即符号表中UNDEF的符号。
集合D： 已定义的符号集。
初始情况下，E、U、D均为空。
1、对于每个输入文件f，如果是目标文件(.o)，则将f加入E，并用f中的符号表修改U、D(在文件f中定义实现的符号是D，在f中引用的符号是U)，然后继续下个文件。
2、如果f是一个静态库(.a)，那么链接器将尝试匹配U中未解析符号与静态库成员(静态库的成员就是.o文件)定义的符号。如果静态库中某个成员m(某个.o文件)定义了一个符号来解析U中引用，那么将m加入E中，
同时使用m的符号表，来更新U、D。对静态库中所有成员目标文件反复进行该过程，直至U和D不再发生变化。此时，静态库f中任何不包含在E中的成员目标文件都将丢弃，链接器将继续下一个文件。
3、当所有输入文件完成后，如果U非空，链接器则会报错，否则合并和重定位E中目标文件，构建出可执行文件。
到这里，为什么会有库的依赖问题已经得到解答：
因为libchild.a依赖于libbase.a，但是libbase.a在libchild.a的左边，导致libbase.a中的目标文件(.o)根本就没有被加载到E中，所以解决方法就是交换两者的顺序。当然也可以使用-lbase -lchild -lbase的方法。

-L、-rpath和-rpath-link的区别

-rpath指定的路径会被记录在生成的可执行程序中，用于运行时
-rpath-link 则只用于链接时

再makefile中一般默认的 lib 的加载路径是/lib /usr/lib 如果想要改变程序运行时的libs的加载路径 就需要用到 -wl , rpath 参数来添加lib 加载路径
O0 O1 表示在不影响编译速率的前提下尽可能的优化程序的大小和运行速率。

O2 表示在牺牲部分编译速率的前提下 支持配置优化参数的优化 尽可能的提高运行速率。

O3 表示 采取多项量算法 提高程序的运行速率（他不惜增大程序的大小）

Os 和O3一样只不过他不会为了以为的提高程序运行速率二曾大程序的大小

内容链接

-pipe 加速编译

gcc -pipe foo.c -o foo
参考连接

例子
现要在目录 mainDir 下编译库libmain.so， 但是其 —依赖于—> libsub.so，sub.so在目录 mainDir / subDir 下，且subDir不在LD_LIBRARY_PATH以及环境变量中。
现有如下执行：
　　1. gcc -share -o libmain.so main.o
　　　　此命令可编译并链接通过，利用ldd libmain.so时没有发现有对libsub.so的依赖，但是ldd -r libmain.so时会发现会有sub库中的函数出现undefined symbol。
　　　　因为libmain.so 依赖于 libsub.o，但是链接时没有添加lsub。
　　2.gcc -share -lsub -o libmain.so main.o
　　　　此命令无法通过编译，会提示/usr/bin/ld: cannot find -lsub。
　　　　因为libsub.so在目录subDir下，而subDir不在LD_LIBRARY_PATH和环境变量中。所以在链接时，gcc无法找到libsub.so。
　　3.gcc -share -L./subDir -lsub -o libmain.so main.o
　　　　此命令可编译并链接通过，但是ldd -r libmain.so时会发现 libsub.so => not found。因为 libsub.o在目录subDir下。
　　4.gcc -share -Wl,-rpath-link=’./subDir’ -L./subDir -lsub -o libmain.so main.o
　　　　此命令可编译并链接通过，但是在ldd -r libmain.so时还是会发现 libsub.so => not found。
　　5.gcc -share -Wl,-rpath=’./subDir’ -L./subDir -lsub -o libmain.so main.o
　　　　此命令可编译并链接通过，而且ldd -r libmain.so也会发现对libsub.so的依赖

-L：只是在编译时指定库的位置，但是运行时无法找到该位置；
　　-rpath和-rpath-link都可以在链接时指定库的路径。
　　　　但是运行时，-rpath-link指定的路径就不再有效，因为链接器没有将库的路径包含进可执行文件中或库中；
　　　　而-rpath指定的路径，已被链接器写入可执行文件中或库中

其他参考：
参考

练手实例
练手实例