linux库

 将库函数打包成一个单元使之能够在运行时被多个进程共享的技术，这种技术能够节省磁盘空间和RAM。

一、 静态库：
1.概念：
    静态库就是一些目标文件的集合，以.a结尾。静态库在程序链接的时候使用，链接器会将程序中使用到函数的代码从库文件中拷贝到应用程序中。一旦链接完成，在执行程序的时候就不需要静态库了。 由于每个使用静态库的应用程序都需要拷贝所用函数的代码，所以静态链接的文件会比较大。
2.创建与应用:
    首先创建库文件libhello.c
1 #include <stdio.h>
2 void hello()
3 {
4 printf("hello, welcome to library world! ");
5 }
    创建头文件libhello.h
1 void hello();
    现在我们创建libhello静态库文件:
    $ gcc -c libhello -o libhello.o
    $ ar rcs libhello.a libhello.o  
    其中ar中的rcs的意思是：r表明将模块加入到静态库中，c表示创建静态库，s表示生产索引。
    我们写一个测试程序:
    $ cat test.c
1 #include <stdio.h>
2 int main(void)
3 {
4 printf("use library hello. ");
5 hello();
6 return 0;
7 }
    编译与链接：
    $ gcc -c test.c -o test.o
    $ gcc test.o -L. -lhello -o test
    说明：-L.表示将当前目录加入到库搜索路径。默认的库搜索路径在/usr/lib目录下。
    另外这里说明一下易混淆的参数-I, 它表示搜索头文件的路径。这样gcc在查找头文件的时候会首先到-I指定的目录查找，然后才是系统默认目录。
    -l参数: -lname表示库搜索目录下的libname.a 或者libname.so文件 ,这也是为什么库文件都以lib开头的原因之一。一个惯例嘛。当然了，如果你的库文件不是libhello,而是hello. 那就不能用-l参数编译了。可以这样：
    gcc test.o -L. hello.a -o test    
    注意: $gcc -L. -lhello test.o -o test 会出错！。
    原因是: -l是链接器选项，必须要放到被编译文件的后面。所以上面的命令中-lhello一定要放到 test.o的后面。
    运行：
    $ ./test
    use library hello.
    hello, welcome to library world!

库是一组预先编译好的函数集合,这些函数需要按照可重用的原则编写,这些函数通常是有关联并执行同一项任务,比如屏幕处理函数库curses和nsurses库.
标准系统库在/lib和/usr/lib中,编译器会自动找到.除此之外的库在使用时需要指定完全路径或用-L/路径和-l标识

静态库和动态库:静态库和动态库是两种共享程序代码的方式，它们的区别是静态库在程序的链接阶段被复制到程序中，程序执行无关；动态库在链接阶段没有被复制到程序中，而是程序在运行时由系统动态加载到内存中以供调用。使用动态库的优点是系统只需载入一次，不同的程序可以得到内存中相同的副本，因此节省了很多内存。
静态库:使gcc -c命令先生成.o文件,再用ar -r命令,将生成的.o文件创建成静态库.a文件
例:ar crv libtest.a a.o b.o
ar即archive,c是create表示创建,r是replacement,表示使用XX文件,v是显示执行过程中的一些信息

静态库.a文件类似windows中的.lib文件,.so文件类似.dll文件

将程序与静态库链接起来有两种方式
cc -g -c prog.c
cc -g -o prog prog.o libdemo.a　　直接指定静态库的名称。-g选项是在编译过的程序中包含调试信息
或者：将静态库放在链接器搜索的其中一个标准目录中(如/usr/lib)，然后使用-l选项指定库名(即库的文件名去除了lib前缀和.a后缀)
cc -g -o prog prog.o -ldemo
如果库不位于链接器搜索的目录中，那么可以只用-L选项指定链接器应该搜索这个额外的目录。
cc -g -o prog prog.o -Lmylibdir -ldemo

二、共享库:
1、共享库的概念：
    共享库以.so结尾. (so == share object) 在程序的链接时候并不像静态库那样在拷贝使用函数的代码，而只是作些标记。然后在程序开始启动运行的时候，动态地加载所需模块。所以，应用程序在运行的时候仍然需要共享库的支持。 共享库链接出来的文件比静态库要小得多。
2、共享库的命名
    一般一个共享库的有三个名字：soname, real-name, linker-name。下面先看实例:
    $ ls -l /usr/lib/libncurses*
    lrwxrwxrwx 1 root root     20 2008-05-25 13:54 libncurses.so -> /lib/libncurses.so.5
    lrwxrwxrwx 1 root root     13 2008-05-26 15:18 libncurses.so.5 -> libtermcap.so

    上面的libncurses.so.5就是soname, 其中ncurses是库名，5分别是主版本号(major)，当然也可以有次版本号(minor)和发行号(release)。(类似于ibncurses.so.5.0.0)
    .so当然表示共享库了。通常soname只是real name的一个链接。
    而libtermcap.so 这是ncurse库的real-name, 也就是包含真是代码实现的文件.libncurses.so 则是linker name,用于应用程序链接的时候的一个搜索名。它通常是soname的一个链接,形式为libname.so。
　  实际上，每一个库都有一个soname，当连接器发现它正在查找的程序库中有这样一个名称，连接器便会将soname嵌入连结中的二进制文件内，而不是它正在运行的实际文件名，在程序执行期间，程序会查找拥有 soname名字的文件，而不是库的文件名，换句话说，soname是库的区分标志。这样做的目的主要是允许系统中多个版本的库文件共存，习惯上在命名库文件的时候通常与soname相同。
3、共享库的装载
    (1) 在所有基于GNU glibc的系统(当然包括Linux)中，在启动一个ELF二进制执行程序时，
    一个特殊的程序"程序装载器"会被自动装载并运行。在linux中，这个程序装载器就是
    /lib/ld-linux.so.X(X是版本号)。它会查找并装载应用程序所依赖的所有共享库。
    被搜索的目录保存在/etc/ls.so.conf文件中，但一般/usr/local/lib并不在搜索之列，至少debian/ubuntu是这样。这似乎是一个系统失误，只好自己加上了。当然，如果程序的每次启动，都要去搜索一番，势必效率不堪忍受。Linux系统已经考虑这一点，对共享库采用了缓存管理。ldconfig就是实现这一功能的工具，其缺省读取/etc/ld.so.conf文件，对所有共享库按照一定规范建立符号连接，然后将信息写入/etc/ld.so.cache。
     /etc/ld.so.cache的存在大大加快了程序的启动速度。
    (2) 当然你也可以通过设置环境变量LD_LIBRARY_PATH来设置ld的装载路径。这样装载器就会首先搜索该变量的目录，然后才是默认目录。但是记住，LD_LIBRARY_PATH是用于开发和测试的，你可以将一些用于测试的替代共享库的目录放到该变量中，类似于/etc/ld.so.preload的作用。但是该变量不应该用于正常用户的正常程序。
    (3) 如果你不使用LD_LIBRARY_PATH环境变量，可以通过如下方式给装载器传入路径:
        $ /lib/ld-linux.so.2 --library-path PATH EXECUTABLE
4、共享库的创建与应用
    (1) 创建共享库:
    gcc -fpic/fPIC -c source.c -o source.o
    gcc -shared -Wl,-soname,your_soname -o library_name file_list library_list
    说明:  -fpic或者-fPIC表明创建position independent code，这通常是创建共享库必须的。
           -Wl 表明给链接器传送参数，所以这里-soname, library_name 为给链接器的参数。
           -shared 表明是使用共享库
    下面是使用a.c和b.c创建共享库的示例：
       gcc -fPIC -g -c -Wall a.c
       gcc -fPIC -g -c -Wall b.c
       gcc -shared -Wl,-soname, libmyab.so.1 -o libmyab.so.1.0.1 a.o b.o -lc
    说明: lc == libc
    几个需要注意的地方：
      a.不推荐使用strip处理共享库，最好不要使用-fomit-frame-pointer编译选项
      b.-fPIC和-fpic都可以产生目标独立代码，具体应用取决于平台，-fPIC是always work，
      尽管其产生的目标文件可能会大些； -fpic产生的代码小，执行速度快，但可能有平台依赖限制。
      c.一般情况下，-Wall,-soname,your_soname编译选项是需要的。当然，-share选项更不能丢。
    (2) 安装使用共享库
    一旦你创建好共享库后就需要安装使用了，最简单的办法是将库拷贝到默认目录下(/usr/lib)。
    然后创建一些符号链接，最简单的方式还是使用ldconfig(8)来处理这里符号链接。最后是重新
    编译链接你的程序,通过-L和-l参数指定库路径就可以了。

gcc -g -fPIC -Wall mod1.c mod2.c mod3.c -shared -o libfoo.so

众所周知，Linux动态库的默认搜索路径是/lib和/usr/lib。动态库被创建后，一般都复制到这两个目录中。当程序执行时需要某动态库，并且该动态库还未加载到内存中，则系统会自动到这两个默认搜索路径中去查找相应的动态库文件，然后加载该文件到内存中，这样程序就可以使用该动态库中的函数，以及该动态库的其它资源了。
在Linux 中，动态库的搜索路径除了默认的搜索路径外，还可以通过以下三种方法来指定。

方法一：在配置文件/etc/ld.so.conf中指定动态库搜索路径。
vi /etc/ld.so.conf
添加 lib目录
ldconfig
方法二：通过环境变量LD_LIBRARY_PATH指定动态库搜索路径。
export LD_LIBRARY_PATH=”$LD_LIBRARY_PATH:/opt/”
方法三：在编译目标代码时指定该程序的动态库搜索路径。
还可以在编译目标代码时指定程序的动态库搜索路径。通过gcc 的参数”-Wl,-rpath,”指定

linux 下有动态库和静态库，动态库以.so为扩展名，静态库以.a为扩展名。二者都使用广泛。本文主要讲动态库方面知识。
基本上每一个linux 程序都至少会有一个动态库，查看某个程序使用了那些动态库，使用ldd命令查看
[root@localhost ~]# ldd /bin/ls
linux-vdso.so.1 => (0x00007fffff600000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007faab7d50000)
librt.so.1 => /lib64/librt.so.1 (0x00007faab7b48000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007faab7940000)
libacl.so.1 => /lib64/libacl.so.1 (0x00007faab7738000)
libc.so.6 => /lib64/libc.so.6 (0x00007faab73a0000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007faab7198000)
/lib64/ld-linux-x86-64.so.2 (0x00007faab7f78000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007faab6f78000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007faab6d70000)
[root@localhost ~]# strace /bin/ls
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib64/libselinux.so.1", O_RDONLY) = 3
open("/lib64/librt.so.1", O_RDONLY) = 3
open("/lib64/libcap.so.2", O_RDONLY) = 3
open("/lib64/libacl.so.1", O_RDONLY) = 3
open("/lib64/libc.so.6", O_RDONLY) = 3
open("/lib64/libdl.so.2", O_RDONLY) = 3
open("/lib64/libpthread.so.0", O_RDONLY) = 3
open("/lib64/libattr.so.1", O_RDONLY) = 3

[root@localhost ~]# ldd /bin/echo
linux-vdso.so.1 => (0x00007fff71a00000)
libc.so.6 => /lib64/libc.so.6 (0x00007f207c5b8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f207c958000)
[root@localhost ~]# strace /bin/echo
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib64/libc.so.6", O_RDONLY) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3

这么多so，是的。使用ldd显示的so，并不是所有so都是需要使用的,虽然没有用到，但是一样有链接进来，那看看程序启动时候有没有去加载它们呢,通过strace查看，有加载，所以必定会影响进程启动速度，所以我们最后不要把无用的so编译进来，所以只要编译进去，就会链接进来，启动时候便会加载，便会影响进程启动速度

linux从程序（program或对象）变成进程（process或进程），要经过哪些步骤呢，这里如果详细的说，估计要另开一篇文章。简单的说分三步：
1、fork进程，在内核创建进程相关内核项，加载进程可执行文件；
2、查找依赖的so，一一加载映射虚拟地址
3、初始化程序变量。
可以看到，第二步中dll依赖越多，进程启动越慢，并且发布程序的时候，这些链接但没有使用的so，同样要一起跟着发布，否则进程启动时候，会失败，找不到对应的so。所以我们不能像上面那样，把一些毫无意义的so链接进来，浪费资源。但是开发人员写makefile 一般有没有那么细心，图省事方便，那么有什么好的办法呢。继续看下去，下面会给你解决方法。

[root@localhost ~]# ldd -u /bin/ls
Unused direct dependencies:

/lib64/libselinux.so.1
/lib64/librt.so.1
/lib64/libcap.so.2
/lib64/libacl.so.1
ldd -u demo 先查看
g++ -Wl,--as-needed -o demo -lz -lm -lrt main.cpp 再重新编译
ldd demo 再查看
ldd -u demo 再查看便没有未用的链接

g++ -o demo -lz -lm -lrt main.cpp 

[root@localhost df]# vi main.cpp
[root@localhost df]# cat main.cpp
#include <stdio.h>
#include <iostream>
#include <string>
using namespace std;

int main()
{
cout << "test" << endl;
return 0;
}

[root@localhost df]# g++ -o demo main.cpp 使用缺省参数编译

[root@localhost df]# ldd demo
linux-vdso.so.1 => (0x00007fffc9200000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f0c61380000)
libm.so.6 => /lib64/libm.so.6 (0x00007f0c610f8000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f0c60ee0000)
libc.so.6 => /lib64/libc.so.6 (0x00007f0c60b48000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0c61690000)
[root@localhost df]# g++ -o demo -lz -lm -lrt main.cpp　　链接一些程序不会用到的so，加入链接压缩库，数学库，线程库，只要编译时链接进来，程序启动时候便会加载，(即使不用，也会加载)
/usr/bin/ld: cannot find -lz
collect2: ld returned 1 exit status
[root@localhost df]# g++ -o demo -lm -lrt main.cpp
[root@localhost df]# ldd demo
linux-vdso.so.1 => (0x00007fff96f98000)
librt.so.1 => /lib64/librt.so.1 (0x00007fdd5a620000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fdd5a318000)
libm.so.6 => /lib64/libm.so.6 (0x00007fdd5a090000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fdd59e78000)
libc.so.6 => /lib64/libc.so.6 (0x00007fdd59ae0000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdd598c0000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdd5a830000)
[root@localhost df]# ./demo
test

[root@localhost df]# ldd -u demo
Unused direct dependencies:

/lib64/librt.so.1
/lib64/libm.so.6
/lib64/libgcc_s.so.1

[root@localhost df]# g++ -Wl,--as-needed -o demo -lm -lrt main.cpp　　重新编译
[root@localhost df]# ldd demo
linux-vdso.so.1 => (0x00007fffea7f0000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f74e0088000)
libc.so.6 => /lib64/libc.so.6 (0x00007f74dfcf0000)
libm.so.6 => /lib64/libm.so.6 (0x00007f74dfa68000)
/lib64/ld-linux-x86-64.so.2 (0x00007f74e0398000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f74df850000)
[root@localhost df]# ldd -u demo
Unused direct dependencies:

[root@localhost df]# vi main.cpp
[root@localhost df]# cat main.cpp
#include <stdio.h>
#include <iostream>
#include <string>
using namespace std;

int main()
{
cout << "test" << endl;
return 0;
}
[root@localhost df]# vi tmp.cpp
写一个最简单的so， tmp.cpp
1. int test()
2. {
3. return 20;
4. }

编译=>链接=》运行
我们知道linux链接so有两种途径：显式和隐式。所谓显式就是程序主动调用dlopen打开相关so;这里需要补充的是，如果使用显示链接，上篇文章讨论的那些问题都不存在。首先,dlopen的so使用ldd是查看不到的。其次，使用dlopen打开的so并不是在进程启动时候加载映射的，而是当进程运行到调用dlopen代码地方才加载该so，也就是说，如果每个进程显示链接a.so;但是如果发布该程序时候忘记附带发布该a.so,程序仍然能够正常启动，甚至如果运行逻辑没有触发运行到调用dlopen函数代码地方。该程序还能正常运行，即使没有a.so.
既然显式加载这么多优点，那么为什么实际生产中很少码农使用它呢, 主要原因还是起使用不是很方便，需要开发人员多写不少代码。所以不被大多数码农使用，还有一个重要原因应该是能提前发现错误，在部署的时候就能发现缺少哪些so，而不是等到实际上限运行的时候才发现缺东少西。
这样就OK了, 不过这样export 只对当前shell有效，当另开一个shell时候，又要重新设置。可以把export LD_LIBRARY_PATH=/tmp 语句写到 ~/.bashrc中，这样就对当前用户有效了，写到/etc/bashrc中就对所有用户有效了。

[root@localhost df]# g++ -fPIC -c tmp.cpp
[root@localhost df]# ls
demo main.cpp tmp.cpp tmp.o
[root@localhost df]# g++ -shared -o libtmp.so tmp.o
[root@localhost df]# ls
demo libtmp.so main.cpp tmp.cpp tmp.o
[root@localhost df]# mv libtmp.so /tmp/
[root@localhost df]# g++ -o demo -L/tmp -ltmp main.cpp
[root@localhost df]# ./demo
./demo: error while loading shared libraries: libtmp.so: cannot open shared object file: No such file or directory
这个错误是最常见的错误了。运行程序的时候找不到依赖的so。一般人使用方法是修改LD_LIBRARY_PATH这个环境变量
这样就OK了, 不过这样export 只对当前shell有效，当另开一个shell时候，又要重新设置。可以把export LD_LIBRARY_PATH=/tmp 语句写到 ~/.bashrc中，这样就对当前用户有效了，写到/etc/bashrc中就对所有用户有效了。
前面链接时候使用 -L/tmp/ -ltmp 是一种设置相对路径方法，还有一种绝对路径链接方法。
g++ -o demo /tmp/libtmp.so main.cpp
所以应该禁止使用绝对路径链接so
[root@localhost df]# ldd demo
linux-vdso.so.1 => (0x00007ffff0400000)
libtmp.so => not found
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fdb6fd68000)
libm.so.6 => /lib64/libm.so.6 (0x00007fdb6fae0000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fdb6f8c8000)
libc.so.6 => /lib64/libc.so.6 (0x00007fdb6f530000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdb70078000)
[root@localhost df]# export LD_LIBRARY_PATH=/tmp
[root@localhost df]# ./demo
test
[root@localhost df]# ldd demo
linux-vdso.so.1 => (0x00007fffa5df8000)
libtmp.so => /tmp/libtmp.so (0x00007ff761468000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007ff761160000)
libm.so.6 => /lib64/libm.so.6 (0x00007ff760ed8000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff760cc0000)
libc.so.6 => /lib64/libc.so.6 (0x00007ff760928000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff761670000)
搜索路径分两种，一种是链接时候的搜索路径，一种是运行时期的搜索路径。像前面提到的 -L/tmp/ 是属于链接时期的搜索路径，即给ld程序提供的编译链接时候寻找动态库路径；而LD_LIBRARY_PATH则既属于链接期搜索路径，又属于运行时期的搜索路径。
这里需要介绍链-rpath链接选项，它是指定运行时候都使用的搜索路径。聪明的同学马上就想到,运行时搜索路径，那它记录在哪儿呢。也像. LD_LIBRARY_PATH那样，每部署一台机器就需要配一下吗。呵呵，不需要..,因为它已经被硬编码到可执行文件内部了。
[root@localhost df]# g++ -o demo -Wl,-rpath /tmp/ -L/tmp/ -ltmp main.cpp
[root@localhost df]# readelf -d demo

Dynamic section at offset 0xb98 contains 25 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libtmp.so]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000f (RPATH) Library rpath: [/tmp/]
看看是吧，编译到elf文件内部了，路径和程序深深的耦合到一起