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中定义：
//file: sayhello.c
#include<stdio.h>
void sayHello()
{
printf("hello!\n");
}
头文件sayhello.h声明函数sayHello()的形式：
//file: sayhello.h
void sayHello();
现在我们希望发布这个sayHello函数的实现，但是不希望别人知道源代码。于是我们可以将sayHello()函数打包成二进制库的形式发布，同时提供一个头文件声明其调用格式。
主程序hello.c调用sayHello()，如下：
//file: hello.c
#include"hello.h"
int main()
{
sayHello();
return 0;
}
生成动态库的过程如下：
[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++与库
这是一个稍微复杂一点的例子。
比如我们要发布一个类，提供这样的头文件声明：
//file: SaySomething.h
class SaySomething
{
public:
void sayhello();
void sayhi();
};
成员函数的定义由两个文件承担：
//file: SayHello.cpp
#include "SaySomething.h"
#include <iostream>
using namespace std;
void SaySomething::sayhello()
{
cout<<"hello"<<endl;
}
//file: SayHi.cpp
#include "SaySomething.h"
#include <iostream>
using namespace std;
void SaySomething::sayhi()
{
cout<<"hi"<<endl;
}
基于同样的理由，内部成员函数的具体实现是不能公开的，头文件是公开对外发布的唯一途径。
先以动态库形式编译：
[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已经生成。
使用：
//file: Main.cpp
#include "SaySomething.h"
int main()
{
SaySomething* sayHello=new SaySomething();
sayHello->sayhello();
sayHello->sayhi();
return 0;
}
编译：
[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
放入系统定义的共享库搜索目录中
一点疑问
动态链接产生的.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目录下，所以为避免不必要的错误加上了绝对路径
