1、指出static library 与 shared library的区别
static library 与 shared library的共同点在于它们都是library，都是编译完成的二进制代码，可供其他程序调用。
对于static library ， 当程序需要使用它时 ， 编译器会将 static library 与程序结合在一起，当结合完成后，程序本身就包含了library的所有内容，故即使将static library删除也可以使用程序。
对于shared library，其与调用其的程序为动态链接关系，调用它的程序并不将库代码包含在内，而是在运行时调用。这样一来生成的程序体积就比static library要小，而如果删除shared library，程序将无法运行。
static牺牲了体积换取了更高的性能和程序的独立性，而shared牺牲了一些性能换取了体积，这两种方法没有好坏之分，只看应用场景的需求。
2、研究创建static library 与 shared library的方法
我们可以使用gcc来创建shared library，并将其与需要调用它的程序进行链接。
首先，我们编写一个test2.c，其包含一个print函数：
#include <stdio.h>
void print();
void print()
{
printf("HW\n");
}
然后，我们编写一个test.c，其中包含一个main函数，调用print函数：
#include <stdio.h>
int main(void)
{
print();
return 0;
}
有了这些准备，我们可以开始把test.c和test2.c编译成二进制目标文件，并且最终连接成为可执行文件了：
gcc -c -Wall -Werror -fPIC test2.c
gcc -shared test2.o
mv a.out libprint.so
gcc -Wall test.c -lprint -L.
对于上述代码，作出详细解释：
首先，gcc -c -Wall -Werror -fPIC test2.c，其中的-c参数告诉gcc要做的是"Compile and assemble, but do not link"，也就是生成没有连接库的二进制目标文件，-Wall与-Werror是告诉gcc产生所有警告并且将警告作为错误来对待，这是为了让gcc以最严格的方式来检查我们的代码，最后的-fPIC是让gcc去“Generate position-independent code”
关于这个"position-independent code"，引用维基百科上的一段解释：
In computing, position-independent code (PIC) or position-independent executable (PIE) is a body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address.
这样的代码在shared library中十分常用，因为它们可以被复用，例如，当一个需要glibc的程序将glibc加载到内存中后，其他程序也可以使用这份数据，而不需要重新加载一次，这优化了性能，减小了内存消耗。
gcc -shared test2.o是告诉gcc去生成shared library代码，也就是我们需要的东西，mv a.out libprint.so语句将生成的shared library从a.out重命名为libprint.so
最后，我们用gcc -Wall test.c -lprint -L.编译test.c源代码，用-lprint指明需要连接的库文件是libprint.so，而-L.指明了libprint.so就在当前文件夹下
接下来我们来试着创建一个static library，依然使用我们上面编写的test.c和test2.c，由于很多gcc参数已在上文解释过，在这里不再重复解释：
gcc -c -Wall -Werror test2.c #注意这里与上文稍有不同，去掉了-fPIC参数，因为我们要创建的是静态库，不需要position-independent code
ar rcs libprint.a test2.o #解释看下文
gcc -static test.c -L. -lprint #-static参数阻止gcc连接动态库
这里重点解释一下ar语句，这句语句在各种教你编译静态库的文章中都有出现，ar官方manual中介绍ar是用来create, modify, and extract from archives的工具，于是我便觉得非常奇怪，这个打包文件的工具为什么需要出现在这里来制作静态库？
经过查找，找到了这段话：
Unix linkers, usually invoked through the C compiler cc, can read ar files and extract object files from them
看样子这里的ar命令只是为了打包多个静态库，给编译提供方便用的，所以，我认为，我们这里只使用一个静态库，用ar命令没有必要，可以直接：
gcc -static test.c test2.o ，经过测试，这种做法确实可行
3、写一个你自己的shared library
4、写一个你自己的static library
5、调用你自己写的上述库
已在第二问回答中回答，略过
6、在探究过程这种提出一个新问题并自行研究解决
问题：
在将我们的主程序test.c与编译好的shared library链接的时候，我们用的是：gcc -Wall test.c -lprint -L.，那么，gcc是如何完成这个动作的呢？是否调用了其他的什么工具？
答案：
调用的是ld，具体的调用参数可以用gcc -v看到，如果想要用ld来手动进行链接，需要彻底了解glibc的结构，这个没有必要而且也不太现实，这里做了一点能说明问题的小实验：
gcc -static -c test2.c #生成test2.o，我们要的static library
gcc -c test.c # 生成test.o，我们接下来要把这两个文件用ld链接起来
之后，我们来试着使用一下ld：
% ld test.o
ld: warning: cannot find entry symbol _start; defaulting to 00000000004000b0
test.o: In function `main':
test.c:(.text+0xa): undefined reference to `print'
可以看到，如果直接让ld链接test.o，它会提示找不到print函数，这个是我们在test2.o这个static library中提供的，而：
ld test.o test2.o
ld: warning: cannot find entry symbol _start; defaulting to 00000000004000b0
test2.o: In function `print':
test2.c:(.text+0xc): undefined reference to `puts'
当我们让ld把test.o与test2.o链接时，它又提示找不到puts函数，这个很明显是由glibc提供的函数，所以，为了用ld手动解决问题，我们还需要知道glibc的具体结构，这个是没有必要的
完
网友评论