Linux下的库****

在linux上编程时，很多时候会用到一些非标准的库(即自己装上去的库)，这些非标准的库安装位置可能不尽相同，这就给我们编写程序时带来了麻烦。
本文就是旨在替和我一样的菜鸟解决这一问题，水平有限，行文难免谬误，望大虾们不吝赐教。

在linux上编程时，很多时候会用到一些非标准的库(即自己装上去的库)，这些非标准的库安装位置可能不尽相同，这就给我们编写程序时带来了麻烦。
本文就是旨在替和我一样的菜鸟解决这一问题，水平有限，行文难免谬误，望大虾们不吝赐教。

1。头文件的位置
gcc默认会在/usr/include目录下寻找头文件，这是标准库的头文件的路径，但非标准的库一般不会把头文件直接放在该目录下，一般的作法是在该目录下创建一个自己的目录，然后在此目录下直接或分门别类(即再创建更深层次的目录，gtk+即一例证)放自己的头文件。如果是这样，gcc编译时是不会找到这些头文件的，我们会看到有“×××: No such file or directory”的出错信息。解决的方法就是用gcc的-I选项列出这些非标准的路径(实际编程当中一般是由pkg-config --cflags 完成这一工作的)。
2。库的位置
gcc默认会链接标准c语言库，但如果所用的库是“舶来品”，gcc自然不会自动链接，如果也没有显式链接的话，在链接阶段就会出现诸如“: undefined reference to `gtk_container_set_border_width'
/tmp/ccvHaxUx.o(.text+0x1af): In function `main':”的错误。 解决的方法就是利用gcc的-l参数显式链接需要链接的库。这样gcc就会按照一种特定的命名规则到默认的目录(/usr/lib和/lib等目录)下去寻找这些库，并自动链接。但如果库放在自己的定义的目录下，gcc还是不能找到的，这种情况下可以用gcc -L来列出非标准库的路径。实际编程中这一工作是由pkg-config --libs完成的。
上面两次提到pkg-config命令，各位可能就会有疑问了：难道pkg-config前知八百年，后知八百年，无所不能？非也，其实pkg-config也有自己的一套规则来提供关于所查询库的信息。
当要查询指定库（如gtk+-2.0库）的信息时，我们要以gtk+-2.0为参数运行pkg-config命令（如pkg-config --libs --cflags gtk+-2.0)。此时，pkg-config会到默认目录（如/usr/lib/pkgconfig目录）以及PKG_CONFIG_PATH指定的目录去找一个配置文件，该文件就记录了所查询的库在该系统上信息。该配置文件的命名规则是：所查询库的名字加上后缀.pc。若要查询gtk+-2.0的信息，则pkg-config会按上面所说的寻找gtk+-2.0.pc。如果找到，万事大吉，直接根据找到的文件的内容显式库的信息。如果找不到以.pc为后缀的配置文件，则显示出错信息提示用户继续寻找。例如:
[leo@leo ~]$ pkg-config --libs --cflags gtkmm-2.0
Package gtkmm-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtkmm-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gtkmm-2.0' found
这就有两种可能：一是gtkmm-2.0.pc没有放在/usr/lib/pkg-config下。二就是gtkmm-2.0根本就没有装。
对应的解决方法：第一种情况直接用find，locate等命令把gtkmm-2.0.pc找出来，把路径加入环境变量PKG_CONFIG_PATH中，再运行命令pkg-config --libs --cflags gtkmm-2.0。第二种情况就只能安装gtkmm-2.0库了。pkg-config 缺省在/usr/lib/pkgconfig 下去找.pc文件，如果没有则报错。若.pc在其他目录下则应该用：export PKG_CONFIG_PATH= /xxx/xxx/pkgconfig/:$PKG_CONFIG_PATH (如，一些.pc文件通常也放在/usr/local/lib/pkgconfig下）。其实pkg-config 和我所熟悉的sdl-config paragui-config.用法很类似。sdl-config paragui-config 仅仅是得到sdl、paragui的一些信息而已。而pkg-config则可以得到其他包的一些信息。pkg-config --cflags --libs paragui 则与paragui-config --cflags --libs 用法一致。pkg-config --cflags --libs freetype2 和freetype2-config --cflags --libs作用一样，不过freetype2的开发者不一定提供freetype2-config 命令，通常给出一个.pc文件，并放到/usr/lib/pkgconfig下，这样pkg-config找的到就可以了。
关pkg-config的更详细的用法请参加pkg-config的manpage：）

如前所述，当显式链接库时，gcc会按自己的规则去寻找库的名字，现在就来说说库的命名规则。
系统中的库分两类，静态库和动态库（关于动态库和静态库的区别以及如何添加自己的库，请参看我在blog上的另一篇文章）。静态库和动态库在命名上的区别就是后缀名不同而已。动态库以.so（意为shared object)结尾，而静态库一.a（意为archive)结尾。由于种种原因，链接时是优先链接动态库的，如果不成功，则链接静态库。
除了有相区别的后缀外，动态和静态库都有相同的前缀lib，这样动态库就有形如libXX.so的形式，相应的，静态库的名字看起来会是这样libXX.a。
比如，用-lm参数链接数学库时，gcc就会去寻找libm.so或libm.a。

或许大家对自己初学linux时的情形仍记忆尤新吧。如果没有一个能较好的解决依赖关系的包管理器，在linux下安装软件将是一件及其痛苦的工作。你装a包时，可能会提示你要先装b包，当你费尽心力找到b包时，可能又会提示你要先安装c包。我就曾被这样的事搞的焦头烂额，至今一提起rpm仍心有余悸，头皮发麻。说是一朝被蛇咬，十年怕井绳怕也不为过。
linux下之所以有这许多的依赖关系，其中一个开发原则真是功不可没。这个原则就是：尽量不重复做别人已经做过的事。换句话说就是尽量充分利用别人的劳动成果。
这就涉及到如何有效的进行代码复用。

1 为什么要使用库？

关于代码复用的途径，一般有两种。

粘贴复制
这是最没有技术含量的一种方案。如果代码小，则工作量还可以忍受，如果代码很庞大，则此法不可取。即便有人原意这样做，但谁又能保证所有的代码都可得到呢？

而库的出现很好的解决了这个问题。
库，是一种封装机制，简单说把所有的源代码编译成目标代码后打成的包。
那么用户怎么能知道这个库提供什么样的接口呢？难道要用nm等工具逐个扫描？
不用担心，库的开发者早以把一切都做好了。除了包含目标代码的库外，一般还会提供一系列的头文件，头文件中就包含了库的接口。为了让方便用户，再加上一个使用说明就差不多完美了。

2 库的分类

2.1 库的分类
根据链接时期的不同，库又有静态库和动态库之分。

静态库是在链接阶段被链接的（好像是废话，但事实就是这样），所以生成的可执行文件就不受库的影响了，即使库被删除了，程序依然可以成功运行。
有别于静态库，动态库的链接是在程序执行的时候被链接的。所以，即使程序编译完，库仍须保留在系统上，以供程序运行时调用。（TODO：链接动态库时链接阶段到底做了什么）

2.2 静态库和动态库的比较
链接静态库其实从某种意义上来说也是一种粘贴复制，只不过它操作的对象是目标代码而不是源码而已。因为静态库被链接后库就直接嵌入可执行文件中了，这样就带来了两个问题。
首先就是系统空间被浪费了。这是显而易见的，想象一下，如果多个程序链接了同一个库，则每一个生成的可执行文件就都会有一个库的副本，必然会浪费系统空间。
再者，人非圣贤，即使是精心调试的库，也难免会有错。一旦发现了库中有bug，挽救起来就比较麻烦了。必须一一把链接该库的程序找出来，然后重新编译。
而动态库的出现正弥补了静态库的以上弊端。因为动态库是在程序运行时被链接的，所以磁盘上只须保留一份副本，因此节约了磁盘空间。如果发现了bug或要升级也很简单，只要用新的库把原来的替换掉就行了。
那么，是不是静态库就一无是处了呢？
答曰：非也非也。不是有句话么：存在即是合理。静态库既然没有湮没在滔滔的历史长河中，就必然有它的用武之地。想象一下这样的情况：如果你用libpcap库编了一个程序，要给被人运行，而他的系统上没有装pcap库，该怎么解决呢？最简单的办法就是编译该程序时把所有要链接的库都链接它们的静态库，这样，就可以在别人的系统上直接运行该程序了。
所谓有得必有失，正因为动态库在程序运行时被链接，故程序的运行速度和链接静态库的版本相比必然会打折扣。然而瑕不掩瑜，动态库的不足相对于它带来的好处在现今硬件下简直是微不足道的，所以链接程序在链接时一般是优先链接动态库的，除非用-static参数指定链接静态库。

2.3 如何判断一个程序有没有链接动态库?
答案是用file实用程序。
file程序是用来判断文件类型的，在file命令下，所有文件都会原形毕露的。
顺便说一个技巧。有时在windows下用浏览器下载tar.gz或tar.bz2文件，后缀名会变成奇怪的tar.tar，到linux有些新手就不知怎么解压了。但linux下的文件类型并不受文件后缀名的影响，所以我们可以先用命令file xxx.tar.tar看一下文件类型，然后用tar加适当的参数解压。
另外，还可以借助程序ldd实用程序来判断。
ldd是用来打印目标程序（由命令行参数指定）所链接的所有动态库的信息的，如果目标程序没有链接动态库，则打印“not a dynamic executable”，ldd的用法请参考manpage。


3 创建自己的库

3.1 创建动态库
创建文件hello.c，内容如下：
#include

void hello(void)
{
printf("Hello World/n");
}

编译生成动态库的命令为：gcc (-fpic) -shared -o libmyfunction.so myfunction.c
    -fpic 使输出的对象模块是按照可重定位地址方式生成的。
    -shared指定把对应的源文件生成对应的动态链接库文件。

用命令gcc -shared hello.c -o libhello.so编译为动态库。可以看到，当前目录下多了一个文件libhello.so。
[leo@leo test]$ file libhello.so
libhello.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped
看到了吧，文件类型是shared object了。
再编辑一个测试文件test.c，内容如下：
int
main()
{
hello();
return 0;
}
这下可以编译了：）
[leo@leo test]$ gcc test.c
/tmp/ccm7w6Mn.o: In function `main':
test.c:(.text+0x1d): undefined reference to `hello'
collect2: ld returned 1 exit status
链接时gcc找不到hello函数，编译失败:(。原因是hello在我们自己创建的库中，如果gcc能找到那才教见鬼呢！ok，再接再厉。
[leo@leo test]$ gcc test.c -lhello
/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lhello
collect2: ld returned 1 exit status
[leo@leo test]$ gcc test.c -lhello -L.
[leo@leo test]$
第一次编译直接编译，gcc默认会链接标准c库，但符号名hello解析不出来，故连接阶段通不过了。
现在用gcc test.c -lhello -L.已经编译成功了，默认输出为a.out。现在来试着运行一下：
[leo@leo test]$ ./a.out
./a.out: error while loading shared libraries: libhello.so: cannot open shared object file: No such file or directory
咦，怎么回事？原来虽然链接时链接器（dynamic linker）找到了动态库libhello.so，但动态加载器(dynamic loader， 一般是/lib/ld-linux.so.2)却没找到。再来看看ldd的输出：
[leo@leo test]$ ldd a.out
linux-gate.so.1 => (0xffffe000)
libhello.so => not found
libc.so.6 => /lib/libc.so.6 (0x40034000)
/lib/ld-linux.so.2 (0x40000000)
果然如此，看到没有，libhello.so => not found。
linux为我们提供了两种解决方法：
1.可以把当前路径加入/etc/ld.so.conf中然后运行ldconfig，或者以当前路径为参数运行ldconfig（要有root权限才行）。
2.把当前路径加入环境变量LD_LIBRARY_PATH中（经过我试验，确实可以成功了）
当然，如果你觉得不会引起混乱的话，可以直接把该库拷入/lib,/usr/lib/等位置（无可避免，这样做也要有权限），这样链接器和加载器就都可以准确的找到该库了。

以前还以为只要连接成功了就一定可以执行成功呢，原来也还不一定的。最近在windows下的程序也有类似的症状。现在windows下的症状也知道原因了。os的基本原理绝对是一致的，无论是linux还是windows它的基本原理肯定是一致的。
我们采用第二种方法：
[leo@leo test]$ export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
[leo@leo test]$ ldd a.out
linux-gate.so.1 => (0xffffe000)
libhello.so => ./libhello.so (0x4001f000)
libc.so.6 => /lib/libc.so.6 (0x40036000)
/lib/ld-linux.so.2 (0x40000000)
哈哈，这下ld-linux.so.2就可以找到libhello.so这个库了。
现在可以直接运行了：
[leo@leo test]$ ./a.out
Hello World


3.2 创建静态库
仍使用刚才的hello.c和test.c。
第一步，生成目标文件。
[leo@leo test]$ gcc -c hello.c
[leo@leo test]$ ls hello.o -l
-rw-r--r-- 1 leo users 840 5月 6 12:48 hello.o
第二步,把目标文件归档。
[leo@leo test]$ ar r libhello.a hello.o
ar: creating libhello.a
OK,libhello.a就是我们所创建的静态库了，简单吧:)
[leo@leo test]$ file libhello.a
libhello.a: current ar archive

下面一行命令就是教你如何在程序中链接静态库的：
[leo@leo test]$ gcc test.c -lhello -L. -static -o hello.static

我们来用file命令比较一下用动态库和静态库链接的程序的区别：
[leo@leo test]$ gcc test.c -lhello -L. -o hello.dynamic
正如前面所说，链接器默认会链接动态库（这里是libhello.so），所以只要把上个命令中的-static参数去掉就可以了。

用file实用程序验证一下是否按我们的要求生成了可执行文件：
[leo@leo test]$ file hello.static hello.dynamic
hello.static: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.6, statically linked, not stripped
hello.dynamic: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.6, dynamically linked (uses shared libs), not stripped
不妨顺便练习一下ldd的用法：
[leo@leo test]$ ldd hello.static hello.dynamic
hello.static:
not a dynamic executable
hello.dynamic:
linux-gate.so.1 => (0xffffe000)
libhello.so => ./libhello.so (0x4001f000)
libc.so.6 => /lib/libc.so.6 (0x40034000)
/lib/ld-linux.so.2 (0x40000000)

OK，看来没有问题，那就比较一下大小先：
[leo@leo test]$ ls -l hello.[ds]*
-rwxr-xr-x 1 leo users 5911 5月 6 12:54 hello.dynamic
-rwxr-xr-x 1 leo users 628182 5月 6 12:54 hello.static
看到区别了吧，链接静态库的目标程序和链接动态库的程序比起来简直就是一个庞然大物！

这么小的程序，很难看出执行时间的差别，不过为了完整起见，还是看一下time的输出吧：
[leo@leo test]$ time ./hello.static
Hello World

real 0m0.001s
user 0m0.000s
sys 0m0.001s
[leo@leo test]$ time ./hello.dynamic
Hello World

real 0m0.001s
user 0m0.000s
sys 0m0.001s
如果程序比较大的话，应该效果会很明显的。