linux下静态库和动态库的创建

linux静态链接库与动态链接库的区别及动态库的创建

一、引言

通常情况下，对函数库的链接是放在编译时期（compile time）完成的。所有相关的对象文件（object file）与牵涉到的函数库（library）被链接合成一个可执行文件（executable file）。程序在运行时，与函数库再无瓜葛，因为所有需要的函数已拷贝到自己门下。所以这些函数库被成为静态库（static libaray），通常文件名为“libxxx.a”的形式。

其实，我们也可以把对一些库函数的链接载入推迟到程序运行的时期（runtime）。这就是如雷贯耳的动态链接库（dynamic link library）技术。

二、动态链接库的特点与优势

首先让我们来看一下，把库函数推迟到程序运行时期载入的好处：

1. 可以实现进程之间的资源共享。

什么概念呢？就是说，某个程序的在运行中要调用某个动态链接库函数的时候，操作系统首先会查看所有正在运行的程序，看在内存里是否已有此库函数的拷贝了。如果有，则让其共享那一个拷贝；只有没有才链接载入。这样的模式虽然会带来一些“动态链接”额外的开销，却大大的节省了系统的内存资源。C的标准库就是动态链接库，也就是说系统中所有运行的程序共享着同一个C标准库的代码段。

2. 将一些程序升级变得简单。用户只需要升级动态链接库，而无需重新编译链接其他原有的代码就可以完成整个程序的升级。Windows 就是一个很好的例子。

3. 甚至可以真正坐到链接载入完全由程序员在程序代码中控制。

程序员在编写程序的时候，可以明确的指明什么时候或者什么情况下，链接载入哪个动态链接库函数。你可以有一个相当大的软件，但每次运行的时候，由于不同的操作需求，只有一小部分程序被载入内存。所有的函数本着“有需求才调入”的原则，于是大大节省了系统资源。比如现在的软件通常都能打开若干种不同类型的文件，这些读写操作通常都用动态链接库来实现。在一次运行当中，一般只有一种类型的文件将会被打开。所以直到程序知道文件的类型以后再载入相应的读写函数，而不是一开始就将所有的读写函数都载入，然后才发觉在整个程序中根本没有用到它们。

三、动态链接库的创建

由于动态链接库函数的共享特性，它们不会被拷贝到可执行文件中。在编译的时候，编译器只会做一些函数名之类的检查。在程序运行的时候，被调用的动态链接库函数被安置在内存的某个地方，所有调用它的程序将指向这个代码段。因此，这些代码必须实用相对地址，而不是绝对地址。在编译的时候，我们需要告诉编译器，这些对象文件是用来做动态链接库的，所以要用地址不无关代码（Position Independent Code （PIC））。

对gcc编译器，只需添加上 -fPIC 标签，如：

gcc -fPIC -c file1.c
gcc -fPIC -c file2.c
gcc -shared libxxx.so file1.o file2.o

注意到最后一行，-shared 标签告诉编译器这是要建立动态链接库。这与静态链接库的建立很不一样，后者用的是 ar 命令。也注意到，动态链接库的名字形式为 “libxxx.so” 后缀名为 “.so”

四、动态链接库的使用

使用动态链接库，首先需要在编译期间让编译器检查一些语法与定义。

这与静态库的实用基本一样，用的是 -Lpath 和 -lxxx 标签。如：

gcc file1.o file2.o -Lpath -lxxx -o program.exe

编译器会先在path文件夹下搜索libxxx.so文件，如果没有找到，继续搜索libxxx.a（静态库）。

在程序运行期间，也需要告诉系统去哪里找你的动态链接库文件。在UNIX下是通过定义名为 LD_LIBRARY_PATH 的环境变量来实现的。只需将path赋值给此变量即可。csh 命令为：

setenv LD_LIBRARY_PATH   your/full/path/to/dll

一切安排妥当后，你可以用 ldd 命令检查是否连接正常。

ldd program.exe

动态链接库*.so的编译与使用- -


动态库*.so在linux下用c和c++编程时经常会碰到，最近在网站找了几篇文章介绍动态库的编译和链接，总算搞懂了这个之前一直不太了解得东东，这里做个笔记，也为其它正为动态库链接库而苦恼的兄弟们提供一点帮助。
1、动态库的编译

下面通过一个例子来介绍如何生成一个动态库。这里有一个头文件：so_test.h，三个.c文件：test_a.c、test_b.c、test_c.c，我们将这几个文件编译成一个动态库：libtest.so。

so_test.h：



#include

#include



void test_a();

void test_b();

void test_c();



test_a.c：



#include "so_test.h"



void test_a()

{

printf("this is in test_a.../n");

}



test_b.c：



#include "so_test.h"



void test_b()

{

printf("this is in test_b.../n");

}



test_a.c：



#include "so_test.h"



void test_c()

{

printf("this is in test_c.../n");

}



将这几个文件编译成一个动态库：libtest.so



$ gcc test_a.c test_b.c test_c.c -fPIC -shared -o libtest.so


2、动态库的链接

在1、中，我们已经成功生成了一个自己的动态链接库libtest.so，下面我们通过一个程序来调用这个库里的函数。程序的源文件为：test.c。

test.c：



#include "so_test.h"



int main()

{

test_a();

test_b();

test_c();



return 0;

}



l 将test.c与动态库libtest.so链接生成执行文件test：



$ gcc test.c -L. -ltest -o test



l 测试是否动态连接，如果列出libtest.so，那么应该是连接正常了



$ ldd test



l 执行test，可以看到它是如何调用动态库中的函数的。
3、编译参数解析
最主要的是GCC命令行的一个选项:
-shared 该选项指定生成动态连接库（让连接器生成T类型的导出符号表，有时候也生成弱连接W类型的导出符号），不用该标志外部程序无法连接。相当于一个可执行文件

l -fPIC：表示编译为位置独立的代码，不用此选项的话编译后的代码是位置相关的所以动态载入时是通过代码拷贝的方式来满足不同进程的需要，而不能达到真正代码段共享的目的。

l -L.：表示要连接的库在当前目录中

l -ltest：编译器查找动态连接库时有隐含的命名规则，即在给出的名字前面加上lib，后面加上.so来确定库的名称

l LD_LIBRARY_PATH：这个环境变量指示动态连接器可以装载动态库的路径。

l 当然如果有root权限的话，可以修改/etc/ld.so.conf文件，然后调用 /sbin/ldconfig来达到同样的目的，不过如果没有root权限，那么只能采用输出LD_LIBRARY_PATH的方法了。
4、注意

调用动态库的时候有几个问题会经常碰到，有时，明明已经将库的头文件所在目录 通过 “-I” include进来了，库所在文件通过“-L”参数引导，并指定了“-l”的库名，但通过ldd命令察看时，就是死活找不到你指定链接的so文件，这时你要作的就是通过修改LD_LIBRARY_PATH或者/etc/ld.so.conf文件来指定动态库的目录。通常这样做就可以解决库无法链接的问题了。

一、 静态库：
1.概念：
    静态库就是一些目标文件的集合，以.a结尾。静态库在程序链接的时候使用，链接器会将程序中使用
    到函数的代码从库文件中拷贝到应用程序中。一旦链接完成，在执行程序的时候就不需要静态库了。
    由于每个使用静态库的应用程序都需要拷贝所用函数的代码，所以静态链接的文件会比较大。
2.创建与应用:
    首先创建库文件libhello.c
    #include <stdio.h>
    void hello()
    {
        printf("hello, welcome to library world!\n");
    }
    创建头文件libhello.h
    void hello();

    现在我们创建libhello静态库文件:
    $ gcc -c libhello -o libhello.o
    $ ar rcs libhello.a libhello.o 
    其中ar中的rcs的意思是： r表明将模块加入到静态库中，c表示创建静态库，s表示生产索引。
   
    我们写一个测试程序:
    $ cat test.c
    #include <stdio.h>
    int main(void)
    {
        printf("use library hello.\n");
        hello();
        return 0;
    }
   
    编译与链接：
    $ gcc -c test.c -o test.o
    $ gcc test.o -L. -lhello -o test
    说明：-L.表示将当前目录加入到库搜索路径。默认的库搜索路径在/usr/lib目录下。
    另外这里说明一下易混淆的参数-I, 它表示搜索头文件的路径。这样gcc在查找头文件的时候会首先
    到-I指定的目录查找，然后才是系统默认目录。
   
    -l参数: -lname表示库搜索目录下的libname.a 或者libname.so文件 ,
    这也是为什么库文件都以lib开头的原因之一。一个惯例嘛。当然了，如果你的库文件不是
    libhello,而是hello. 那就不能用-l参数编译了。 可以这样：
    gcc test.o -L. hello.a -o test
   
    注意: $gcc -L. -lhello test.o -o test 会出错！。
    原因是: -l是链接器选项，必须要放到被编译文件的后面。 所以上面的命令中-lhello一定要
    放到 test.o的后面。

    运行：
    $ ./test
    use library hello.
    hello, welcome to library world!
   
   
二、共享库:
1、共享库的概念：
    共享库以.so结尾. (so == share object) 在程序的链接时候并不像静态库那样在拷贝
    使用函数的代码，而只是作些标记。然后在程序开始启动运行的时候，动态地加载所需模块。所以，
    应用程序在运行的时候仍然需要共享库的支持。 共享库链接出来的文件比静态库要小得多。

2、共享库的命名
    一般一个共享库的有三个名字：soname, real-name, linker-name。下面先看实例:
    $ ls -l /usr/lib/libncurses*
    lrwxrwxrwx 1 root root     20 2008-05-25 13:54 libncurses.so -> /lib/libncurses.so.5
    lrwxrwxrwx 1 root root     13 2008-05-26 15:18 libncurses.so.5 -> libtermcap.so

    上面的libncurses.so.5就是soname, 其中ncurses是库名，5分别是主版本号(major)，
    当然也可以有次版本号(minor)和发行号(release)。(类似于libncurses.so.5.0.0)
    .so当然表示共享库了。通常soname只是real name的一个链接。
    而libtermcap.so 这是ncurse库的real-name, 也就是包含真是代码实现的文件.
    libncurses.so 则是linker name,用于应用程序链接的时候的一个搜索名。 它通常是soname的
    一个链接,形式为libname.so

3、共享库的装载
    (1) 在所有基于GNU glibc的系统(当然包括Linux)中，在启动一个ELF二进制执行程序时，
    一个特殊的程序"程序装载器"会被自动装载并运行。在linux中，这个程序装载器就是
    /lib/ld-linux.so.X(X是版本号)。它会查找并装载应用程序所依赖的所有共享库。
    被搜索的目录保存在/etc/ls.so.conf文件中，但一般/usr/local/lib并不在搜索之列，
    至少debian/ubuntu是这样。这似乎是一个系统失误，只好自己加上了。当然，如果程序的每次启动，
    都要去搜索一番，势必效率不堪忍受。Linux系统已经考虑这一点，对共享库采用了缓存管理。ldconfig
    就是实现这一功能的工具，其缺省读取/etc/ld.so.conf文件，对所有共享库按照一定规范建立
    符号连接，然后将信息写入/etc/ld.so.cache。
     /etc/ld.so.cache的存在大大加快了程序的启动速度。

    (2) 当然你也可以通过设置环境变量LD_LIBRARY_PATH来设置ld的装载路径。这样装载器就会
    首先搜索该变量的目录，然后才是默认目录。但是记住，LD_LIBRARY_PATH是用于开发和测试的，