Linux下如何用GCC编译动态库

本文主要解决以下几个问题

1 为什么要使用库？

2 库的分类

3 创建自己的库

或许大家对自己初学 Linux时的情形仍记忆尤新吧。如果没有一个能较好的解决依赖关系的包管理器，在Linux下安装软件将是一件及其痛苦的工作。你装a包时，可能会提示你要先装b包，当你费尽心力找到b包时，可能又会提示你要先安装c包。我就曾被这样的事搞的焦头烂额，至今一提起rpm仍心有余悸，头皮发麻。说是一朝被蛇咬，十年怕井绳怕也不为过。

Linux下之所以有这许多的依赖关系，其中一个开发原则真是功不可没。这个原则就是：尽量不重复做别人已经做过的事。换句话说就是尽量充分利用别人的劳动成果。

这就涉及到如何有效的进行代码复用。

1 为什么要使用库？

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

粘贴复制

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

而库的出现很好的解决了这个问题。

库，是一种封装机制，简单说把所有的源代码编译成目标代码后打成的包。

那么用户怎么能知道这个库提供什么样的接口呢？难道要用nm等工具逐个扫描？

2 库的分类

2.1 库的分类

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

静态库是在链接阶段被链接的（好像是废话，但事实就是这样），所以生成的可执行文件就不受库的影响了，即使库被删除了，程序依然可以成功运行。

有别于静态库，动态库的链接是在程序执行的时候被链接的。所以，即使程序编译完，库仍须保留在系统上，以供程序运行时调用。（TODO：链接动态库时链接阶段到底做了什么）

2.2 静态库和动态库的比较

链接静态库其实从某种意义上来说也是一种粘贴复制，只不过它操作的对象是目标代码而不是源码而已。因为静态库被链接后库就直接嵌入可执行文件中了，这样就带来了两个问题。

首先就是系统空间被浪费了。这是显而易见的，想象一下，如果多个程序链接了同一个库，则每一个生成的可执行文件就都会有一个库的副本，必然会浪费系统空间。

再者，人非圣贤，即使是精心调试的库，也难免会有错。一旦发现了库中有bug，挽救起来就比较麻烦了。必须一一把链接该库的程序找出来，然后重新编译。

而动态库的出现正弥补了静态库的以上弊端。因为动态库是在程序运行时被链接的，所以磁盘上只须保留一份副本，因此节约了磁盘空间。如果发现了bug或要升级也很简单，只要用新的库把原来的替换掉就行了。

那么，是不是静态库就一无是处了呢？

答曰：非也非也。不是有句话么：存在即是合理。静态库既然没有湮没在滔滔的历史长河中，就必然有它的用武之地。想象一下这样的情况：如果你用libpcap库编了一个程序，要给被人运行，而他的系统上没有装pcap库，该怎么解决呢？最简单的办法就是编译该程序时把所有要链接的库都链接它们的静态库，这样，就可以在别人的系统上直接运行该程序了。

所谓有得必有失，正因为动态库在程序运行时被链接，故程序的运行速度和链接静态库的版本相比必然会打折扣。然而瑕不掩瑜，动态库的不足相对于它带来的好处在现今硬件下简直是微不足道的，所以链接程序在链接时一般是优先链接动态库的，除非用-static参数指定链接静态库。