Part 1. 需求分析：为什么要使用二进制库？

 

答案在于两个方面：

1)         隐藏源代码的需要。

放眼现在市面上各个中间件软件提供商，所提供的产品绝大多数都是以二进制库的形式发布的。流行的比如Linux下的Qt图形库，Windows下微软的DirectX图形接口、.NET基类，以及嵌入式平台上的MiniGUI等等。在Linux下静态库和动态库文件的扩展名通常为.lib和.so(Shared Object)，而Windows下动态库也称作动态链接库，扩展名为.dll(Dynamic Link Library)。

2)         模块化、层次化设计的需要。

一旦某个软件模块设计完成，可以将其打包成一个独立的库文件。这样系统其他部分就可以按照其提供的接口进行调用，而无须考虑代码层次的兼容性。其次，库文件是已经编译好的二进制文件，被调用的库只需要静态或动态地链接到主调代码中即可，而无需再次编译库的源代码，大大提高了编译的速度和效率。

下面在Linux环境中使用流行的gcc编译器来演示这两种库的建立和使用。

 

Part 2. 案例1：C与动态共享库

 

假设有一个简单的任务（经典的helloworld例子）

有一个sayHello的方法在sayhello.c中定义：

头文件sayhello.h声明函数sayHello()的形式：

现在我们希望发布这个sayHello函数的实现，但是不希望别人知道源代码。于是我们可以将sayHello()函数打包成二进制库的形式发布，同时提供一个头文件声明其调用格式。

主程序hello.c调用sayHello()，如下：

生成动态库的过程如下：

[sonic@Rex dynamic-lib-gcc]$ gcc -c -fpic sayhello.c

这样就生成了一个sayhello.o的目标文件。

参数-c: 编译或汇编源文件,但是不作连接.编译器输出对应于源文件的目标文件.

参数-fpic: Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine.

[sonic@Rex dynamic-lib-gcc]$ gcc -shared sayhello.o -o libHello.so

共享库libHello.so就生成好了。

 

现在假设第三方客户需要使用我们提供的共享库，只需要提供libHello.so和hello.h就行了。（hello.h包含于主程序hello.c中）

[sonic@Rex dynamic-lib-gcc]$ gcc hello.c sayhello.so -o hello

把主程序文件和打包好的共享库文件一起编译，最后得到的文件是

[sonic@Rex dynamic-lib-gcc]$ ls

hello  hello.c  libHello.so  sayhello.h

但是这样还不能运行：

[sonic@Rex dynamic-lib-gcc]$ ./hello

./hello: error while loading shared libraries: libHello.so: cannot open shared object file: No such file or directory

这是因为编译hello时用到了共享库，而运行的时候系统只在几个固定的目录进行查找：

/lib、/usr/lib，其余的在配置文件/etc/ld.so.conf中指定。

这里有两种选择，一是把libHello.so拷入系统指定的目录，一是自己建一个专门放置共享库的目录。

比如/lib/local/shared-lib就是一个不错的选择。

修改/etc/ld.so.conf，将目录加入其中。

把libHello.so复制到/lib/local/shared-lib，然后以root账户运行/sbin/ldconfig更新系统缓存。

Ok，现在运行：

[sonic@Rex dynamic-lib-gcc]$ ./hello

hello!

Bingo！试验成功！

用ldd检查一下编译完成的hello可执行文件：

[sonic@Rex dynamic-lib-gcc]$ /usr/bin/ldd[1] hello

        libHello.so=> /usr/local/shared-lib/libHello.so (0x00a26000)

        libc.so.6 => /lib/tls/libc.so.6 (0x001d0000)

        /lib/ld-linux.so.2 (0x001b7000)

可以发现红色标记的那一行是我们提供的共享库。

 

Part 3. 案例2：C++与库

 

这是一个稍微复杂一点的例子。

比如我们要发布一个类，提供这样的头文件声明：

成员函数的定义由两个文件承担：

 

基于同样的理由，内部成员函数的具体实现是不能公开的，头文件是公开对外发布的唯一途径。

 

先以动态库形式编译：

[sonic@Rex dynamic-lib-g++]$ g++ -c -fpic SayHello.cpp SayHi.cpp

生成了两个目标文件：SayHello.o和SayHi.o。

参数-c和-fpic与上例含义一致。

[sonic@Rex dynamic-lib-g++]$g++ -shared SayHello.o SayHi.o -o libSay.so

库文件libSay.so已经生成。

使用：

编译：

[sonic@Rex dynamic-lib-g++]$ g++ Main.cpp libSay.so -o hello2

同样，将libSay.so放入之前建立的共享库目录/lib/local/shared-lib，运行：

[sonic@Rex dynamic-lib-g++]$ ./hello2

hello

hi

用ldd查看hello2:

[sonic@Rex dynamic-lib-g++]$ /usr/bin/ldd hello2

        libSay.so => /usr/local/shared-lib/libSay.so (0x0032b000)

        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00a39000)

        libm.so.6 => /lib/tls/libm.so.6 (0x00301000)

        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0090f000)

        libc.so.6 => /lib/tls/libc.so.6 (0x001d0000)

        /lib/ld-linux.so.2 (0x001b7000)

结论是一致的。

 

还有一种方案是采用静态库的形式发布，当然，效果是一样的，达到了隐藏代码的目的。

[sonic@Rex static-lib-g++]$ g++ -c SayHello.cpp SayHi.cpp

这里没有使用-fpic选项，得到了两个同前缀的.o目标文件。

[sonic@Rex static-lib-g++]$ ar -r libSay.a SayHello.o SayHi.o

使用ar工具打包成.a文件（archive），编译：

[sonic@Rex static-lib-g++]$ g++ Main.cpp libSay.a -o hello3

这次直接运行即可：

[sonic@Rex static-lib-g++]$ ./hello3

hello

hi

使用ldd查看的结果中也没有libSay的项了：

[sonic@Rex static-lib-g++]$ /usr/bin/ldd hello3

        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00a39000)

        libm.so.6 => /lib/tls/libm.so.6 (0x00301000)

        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0090f000)

        libc.so.6 => /lib/tls/libc.so.6 (0x001d0000)

        /lib/ld-linux.so.2 (0x001b7000)

 

Part 4. 比较与分析

 

现在比较一下静态链接和动态链接。

静态链接下的各中间文件的最终可执行文件：

[sonic@Rex static-lib-g++]$ ll

-rw-------  1 sonic sonic     153 Oct  3 13:50 Main.cpp

-rw-------  1 sonic sonic     133 Oct  3 13:50 SayHello.cpp

-rw-rw-r--  1 sonic sonic    2648 Oct  3 21:43 SayHello.o

-rw-------  1 sonic sonic     128 Oct  3 13:50 SayHi.cpp

-rw-rw-r--  1 sonic sonic    2636 Oct  3 21:43 SayHi.o

-rw-------  1 sonic sonic      71 Oct  3 13:50 SaySomething.h

-rwxrwxr-x  1 sonic sonic    8230 Oct  3 21:47 hello3

-rw-rw-r--  1 sonic sonic    5592 Oct  3 21:45 libSay.a

动态链接下的各中间文件的最终可执行文件：

[sonic@Rex dynamic-lib-g++]$ ll

-rw-------  1 sonic sonic  153 Oct  3 13:57 Main.cpp

-rw-------  1 sonic sonic  133 Oct  3 13:57 SayHello.cpp

-rw-rw-r--  1 sonic sonic 3008 Oct  3 21:32 SayHello.o

-rw-------  1 sonic sonic  128 Oct  3 13:57 SayHi.cpp

-rw-rw-r--  1 sonic sonic 3000 Oct  3 21:32 SayHi.o

-rw-------  1 sonic sonic   71 Oct  3 13:57 SaySomething.h

-rwxrwxr-x  1 sonic sonic 5669 Oct  3 21:37 hello2

-rwxrwxr-x  1 sonic sonic 7941 Oct  3 21:34 libSay.so

 

	中间文件	库文件	最终可执行文件
静态链接	2648+2636	5592	8230
动态链接	3008+3000	7941	5569

比较对应的文件发现，中间目标文件动态链接比静态略大，库文件动态链接明显大于静态，原因可能跟动态链接较静态链接更为复杂的机制有关。

最终可执行文件静态链接明显大于动态链接，原因很明显，动态链接顾名思义就是用到的时候才进行加载，因此主程序本身并不包含库。而静态链接就是把库在编译的时候就加载到可执行文件中，因此在运行时也不像同态链接那样需要库的支持。

 

这样一来，C/C++中头文件和库文件的关系就非常清楚了。

如下表所示。

	头文件	静态库	动态库
内容	只提供函数、类以及全局变量、宏的申明，而不提供具体的实现（即源代码）	函数、类的具体实现的二进制目标代码	函数、类的具体实现的二进制目标代码
调用方式	头文件被预处理器(cpp)以直接插入代码的方式被包含进主调源代码中（include）	由链接器(ld)在编译期（静态）链接到主调二进制代码中	由链接器(ld)在运行期（动态）链接到主调二进制代码中
使用	源代码中#include，gcc参数-include headerfile	gcc参数-l library_name	放入系统定义的共享库搜索目录中

 

Part 5. 一点疑问

 

动态链接产生的.so文件在和主程序文件一起编译的时候不能使用-static选项。如果强制使用的话，虽说可以通过链接，但是执行的时候会发生这样的错误：

[sonic@Rex dynamic-lib-g++]$ g++ -static Main.cpp libSay.so

[sonic@Rex dynamic-lib-g++]$ ./a.out

-bash: ./a.out: /usr/lib/libc.so.1: bad ELF interpreter: No such file or directory

而静态链接产生的.a文件时可以和主程序文件一起用-static编译的。

[sonic@Rex static-lib-g++]$ g++  -static Main.cpp libHello.a

[sonic@Rex static-lib-g++]$ ./a.out

hello

hi 

 

---

[1]如果安装过Intel的arm-linux交叉工具链，默认的ldd可能会定位到arm-linux目录下，所以为避免不必要的错误加上了绝对路径