linux 库

beyes

概念：
库是一种软件组件技术，库里面封装了数据和函数，提供给用户程序调用。库的使用可以使程序模块化，提高程序的编译速度，实现代码重用，使程序易于升级。

在 /usr/lib 和 /lib 目录中可以找到绝大多数的共享库。连接时，将首先搜索这两个目录。有一些库也可能放在特定的目录中，在 /etc/ld.so.conf 配置文件中给出了这些目录的列表，如：

beyes@linux-beyes:/media/disk-2> cat /etc/ld.so.conf
/usr/X11R6/lib/Xaw3d
/usr/X11R6/lib
/usr/lib/Xaw3d
/usr/i386-suse-linux/lib
/usr/local/lib
/opt/kde3/lib
include /etc/ld.so.conf.d/*.conf

连接程序也会对列出的这些目录进行搜索。在默认情况下，Linux 将首先搜索指定库的共享版本，如果找不到，才会去搜索静态版本。

在对共享库进行更新或安装新库后，必须运行 ldconfig 命令 /etc/ld.so.conf 文件中相应的项( 如果使用 RPM 进行安装，一般会自动进行更新，不过也不能保证这一点 )。

使用库的优点有：

可以使得程序模块化；
可以加快程序的再编译；
可以实现代码重用；
可以使得程序便于升级。

库的分类：
库可以有三种使用形式：静态、共享 和 动态。
静态库的代码在编译时就已经连接应用程序中；
共享库只是在程序开始运行时才载入，在编译时只是简单地指定需要使用的库函数；
动态库是共享库的另一种变化形式，虽然动态库也是程序运行时载入，但与共享库不同的是，使用的库函数不是在程序运行开始，而是在程序中的语句需要使用时才载入。动态库可以在程序运行期间释放动态库所占用的内存，腾出空间供其他程序使用。

由于共享库和动态库并没有在程序中包含库函数的内容，只是包含了对库函数的引用，因此代码的规模比较小。

在默认情况下，系统优先使用共享库，也可以添加 -static 选项强制使用静态库。

库的命名：
( 1 ) 静态库
按照习惯，静态库一般以 ".a" 作为文件后缀名，组成如下：

lib + 库名 + .a
如：
beyes@linux-beyes:/media/disk-2> ls /usr/lib/*.a
/usr/lib/libaa.a                         /usr/lib/libreadline.a
/usr/lib/libaio.a                        /usr/lib/libresolv.a
... ...

( 2 )共享库
每个共享库都有一个特定的搜名 ( soname )，组成如下：

lib + 库名 + .so + . + version
如：
lrwxrwxrwx  1 root root      17 04-18 12:51 libtirpc.so.1 -> libtirpc.so.1.0.9
lrwxrwxrwx  1 root root      18 04-18 12:51 libxcrypt.so.2 -> libxcrypt.so.2.0.0

在文件系统中，搜名是一个指向实名的符号链接。

每个共享库都有一个实名( real name )，真正包含库代码，组成如下：

搜名 + . + 子版本号 + . + 发布号
如：
libtirpc.so.1.0.9
libxcrypt.so.2.0.0

另外，共享库还有一个名称，一般用于编译连接，称为连名( linker name )，它可以被认为是没有任何版本号的搜名。

beyes

创建静态库的步骤如下：

在一个头文件中声明静态库所导出的函数。
在一个源文件中实现静态库所导出的函数。
编译源文件，生成可执行代码。
将可执行代码所在的目标文件加入到某个静态库中，并将静态库拷贝到系统默认的存放苦文件的目录下。

1、创建一个头文件，这个头文件中包含有后面要创建的静态库中含有的函数的声明：
beyes@linux-beyes:~/C/lib> cat mylib.h

#ifndef _mylib_h_
#define _mylib_h_

void welcome();
void outstring(const char *str);

#endif

2、在一个源文件中实现静态库所导出的函数( 头文件中声明的函数原型的具体实现 )：
beyes@linux-beyes:~/C/lib> cat mylib.c

#include "mylib.h"
#include <stdio.h>

void welcome()
{
    printf("Welcome to libmylib\\n");
}

void outstring(const char *str)
{
    if (str != NULL) {
        printf("%s", str);
    }
}

3、编译 mylib.c 生成目标文件：

gcc -o mylib.o -c mylib.c

4、将目标文件加入静态库中，静态库名为 libmylib.a

beyes@linux-beyes:~/C/lib> ar rcs libmylib.a mylib.o

5、将静态库拷贝到 Linux 的库目录 ( /usr/lib 或 /lib ) 下：

beyes@linux-beyes:~/C/lib> sudo cp libmylib.a /usr/lib

下面测试使用这个库，测试程序为：

#include "mylib.h"
#include <stdio.h>

int main()
{
    printf("create and use library: \\n");
    welcome();
    outstring("It's successful\\n");
}

假如如下编译：

beyes@linux-beyes:~/C/lib> gcc -o test.exe test.c
/tmp/ccoDYPTM.o: In function `main':
test.c:(.text+0x1e): undefined reference to `welcome'
test.c:(.text+0x2a): undefined reference to `outstring'
collect2: ld returned 1 exit status

由上可见，提示我们之前创建的两个函数未定义。

使用这两个已加到库中的函数，应该如下编译：

beyes@linux-beyes:~/C/lib> gcc -o test.exe test.c -lmylib

运行生成的程序：

beyes@linux-beyes:~/C/lib> ./test.exe
create and use library:
Welcome to libmylib
It's successful

关于 ar 命令详细用法见：http://www.groad.net/bbs/read.php?tid=958

beyes

在某种意义上，动态链接库也是一种可执行文件。按一般规则，动态链接库以 .so 为后缀。

创建动态链接库( mylib.c )：

gcc -fPIC -o mylib.o -c mylib.c

-fPIC 选项告诉 GCC 产生的代码不要包含对函数和变量具体内存位置的引用，这是因为现在还无法知道使用该消息代码的应用程序会将它连接到哪一段内存地址空间。这样编译输出的文件 mylib.o 可以用于创建共享函数库( 动态链接库 )，所以再继续使用下面的命令：

beyes@linux-beyes:~/C/lib> gcc -shared -o libmylib.so mylib.o

上面创建动态链接库时用了两个命令，这两个命令也可以合起来写：

gcc -fPIC -shared -o libmylib.so mylib.o

动态链接库创建后就可以使用了。 Linux 下有两种方式调用动态链接库中的函数，一种是像使用静态库一样，通过 gcc 命令调用，如下：

beyes@linux-beyes:~/C/lib> gcc -o test.exe test.c ./libmylib.so

或者：

cp libmylib.so /usr/lib/libmylib.so
gcc -o test.exe test.c /usr/lib/libmylib.so

注意：引用动态链接库时，必须含有路径。如果只是使用 libmylib.so , 则必须确保这个库所在目录包含在 PATH 环境变量中。

运行程序，输出：

beyes@linux-beyes:~/C/lib> ./test.exe
create and use library:
Welcome to libmylib
It's successful

---

现在先把 libmylib.so 拷贝一份到 /lib 目录下，然后将其改名：

sudo mv /lib/libmylib.so /lib/libmylib.so.bak

这样，运行时动态 连接器/加载器 -ld-linux 在自动搜索标准系统目录 /lib 或者 /usr/lib 时，自然找不到共享库，但我们有一份共享库文件仍然在源码所在的目录下，这时可以用以下命令：

beyes@linux-beyes:~/C/lib> gcc -o test.exe -lmylib -L. test.c

其中, "-L." 标记告诉 GCC 函数库可能位于当前目录中，否则连接器会去查找标准系统函数库目录。因为这里我们改名了，当然在系统目录下找不到可用的函数库。如果确定在 /lib 或 /usr/lib 里存在所需要的库，那么可以直接：

beyes@linux-beyes:~/C/lib> gcc -o test.exe test.c -lmylib

注意，上面的 -lmylib 只写出了 mylib ，而不是要写出 libmylib。
另外，-l 选项是告诉GCC 驱动程序在连接阶段就引用共享函数库 libmylib.so 。

可以使用 ldd 命令发现一个特定应用程序需要使用的函数库。ldd 搜索标准系统函数库路径并显示一个特定程序使用的函数库版本，如下：

beyes@linux-beyes:~/C/lib> ldd test.exe
    linux-gate.so.1 =>  (0xffffe000)
    libc.so.6 => /lib/libc.so.6 (0xb7df0000)
    /lib/ld-linux.so.2 (0xb7f74000)

由输出可见，似乎没有发现程序使用了 /lib/libmylib.so 这个库。原因是，这个 test.exe 文件是用了由上面的 gcc -o test.exe test.c -lmylib 编译输出的结果。如上面蓝色字体所示，共享库中的函数因为用了 -lmylib 标记后已经在连接阶段就已经包含到程序中。

现在删除掉这个 test.exe 文件，用下面的命令再编译生成可执行文件 test.exe :

gcc -o test.exe test.c /lib/libmylib.so

再ldd 查看：

beyes@linux-beyes:~/C/lib> ldd test.exe
    linux-gate.so.1 =>  (0xffffe000)
    /lib/libmylib.so (0xb7fb7000)
    libc.so.6 => /lib/libc.so.6 (0xb7e34000)
    /lib/ld-linux.so.2 (0xb7fbb000)

这次，“真正”的是“动态“时才连接函数，所以看到了 test.exe 使用了之前自定义的共享库 libmylib.so 。

假如把 /lib/libmylib.so 先更名一下：

beyes@linux-beyes:~/C/lib> sudo mv /lib/libmylib.so /lib/libmylib.so.bak
beyes@linux-beyes:~/C/lib> ls /lib/libmylib.so.bak
/lib/libmylib.so.bak

那么再用 ldd 查看可执行文件 test.exe :

beyes@linux-beyes:~/C/lib> ldd test.exe
    linux-gate.so.1 =>  (0xffffe000)
    /lib/libmylib.so => not found
    libc.so.6 => /lib/libc.so.6 (0xb7e3a000)
    /lib/ld-linux.so.2 (0xb7fbe000)

由上面输出可见，ldd 显示的结果中告诉我们，所需要的 libmylib.so 不存在了！

如果强行运行这个程序，则输出：

beyes@linux-beyes:~/C/lib> ./test.exe
./test.exe: error while loading shared libraries: /lib/libmylib.so: cannot open shared object file: No such file or directory

---

Linux 共享库：LD_LIBRARY_PATH 与ld.so.conf[转]
Linux 运行的时候，是如何管理共享库(*.so)的？在 Linux 下面，共享库的寻找和加载是由 /lib/ld.so 实现的。 ld.so 在标准路经(/lib, /usr/lib) 中寻找应用程序用到的共享库。

但是，如果需要用到的共享库在非标准路经，ld.so 怎么找到它呢？

目前，Linux 通用的做法是将非标准路经加入 /etc/ld.so.conf，然后运行 ldconfig 生成 /etc/ld.so.cache。 ld.so 加载共享库的时候，会从 ld.so.cache 查找。

传统上，Linux 的先辈 Unix 还有一个环境变量：LD_LIBRARY_PATH 来处理非标准路经的共享库。ld.so 加载共享库的时候，也会查找这个变量所设置的路经。LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./libexport LD_LIBRARY_PATH但是，有不少声音主张要避免使用 LD_LIBRARY_PATH 变量，尤其是作为全局变量。这些声音是：
* LD_LIBRARY_PATH is not the answer - http://prefetch.net/articles/linkers.badldlibrary.html
* Why LD_LIBRARY_PATH is bad - http://xahlee.org/UnixResource_dir/_/ldpath.html
* LD_LIBRARY_PATH - just say no - http://blogs.sun.com/rie/date/20040710
解决这一问题的另一方法是在编译的时候通过 -R<path> 选项指定 run-time path。



1. 往/lib和/usr/lib里面加东西，是不用修改/etc/ld.so.conf的，但是完了之后要调一下ldconfig，不然这个library会找不到

2. 想往上面两个目录以外加东西的时候，一定要修改/etc/ld.so.conf，然后再调用ldconfig，不然也会找不到
比如安装了一个mysql到/usr/local/mysql，mysql有一大堆library在/usr/local/mysql/lib下面，这时就需要在/etc/ld.so.conf下面加一行/usr/local/mysql/lib，保存过后ldconfig一下，新的library才能在程序运行时被找到。

3.如果想在这两个目录以外放lib，但是又不想在/etc/ld.so.conf中加东西（或者是没有权限加东西）。那也可以，就是export一个全局变量LD_LIBRARY_PATH，然后运行程序的时候就会去这个目录中找library。一般来讲这只是一种临时的解决方案，在没有权限或临时需要的时候使用。

4. ldconfig做的这些东西都与运行程序时有关，跟编译时一点关系都没有。编译的时候还是该加-L就得加，不要混淆了。

5. 总之，就是不管做了什么关于library的变动后，最好都ldconfig一下，不然会出现一些意想不到的结果。不会花太多的时间，但是会省很多的事。


LD_LIBRARY_PATH 这个环境变量是大家最为熟悉的，它告诉loader：在哪些目录中可以找到共享库。可以设置多个搜索目录，这些目录之间用冒号分隔开。在linux下，还提供了另外一种方式来完成同样的功能，你可以把这些目录加到/etc/ld.so.conf中，然后调用ldconfig。当然，这是系统范围内全局有效的，而环境变量只对当前shell有效。按照惯例，除非你用上述方式指明，loader是不会在当前目录下去找共享库的，正如shell不会在当前目前找可执行文件一样。