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

最新推荐文章于 2022-07-16 14:02:38 发布

jsj020122

最新推荐文章于 2022-07-16 14:02:38 发布

阅读量755

点赞数

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是用于开发和测试的，
    你可以将一些用于测试的替代共享库的目录放到该变量中，类似于/etc/ld.so.preload的作用。
    但是该变量不应该用于正常用户的正常程序。

    (3) 如果你不使用LD_LIBRARY_PATH环境变量，可以通过如下方式给装载器传入路径:
        $ /lib/ld-linux.so.2 --library-path PATH EXECUTABLE

4、共享库的创建与应用
    (1) 创建共享库:
    gcc    -fpic/fPIC -c source.c -o source.o
    gcc -shared -Wl,-soname,your_soname -o library_name file_list library_list
    说明: -fpic或者-fPIC表明创建position independent code，这通常是创建共享库必须的。
         -Wl 表明给链接器传送参数，所以这里-soname, library_name 为给链接器的参数。
        -shared 表明是使用共享库

    下面是使用a.c和b.c创建共享库的示例：
    gcc -fPIC -g -c -Wall a.c
       gcc -fPIC -g -c -Wall b.c
       gcc -shared -Wl,-soname, libmyab.so.1 -o libmyab.so.1.0.1 a.o b.o -lc
    说明: lc == libc

    几个需要注意的地方：
    a.不推荐使用strip处理共享库，最好不要使用-fomit-frame-pointer编译选项
    b.-fPIC和-fpic都可以产生目标独立代码，具体应用取决于平台，-fPIC是always work，
    尽管其产生的目标文件可能会大些； -fpic产生的代码小，执行速度快，但可能有平台依赖限制。
    c.一般情况下，-Wall,-soname,your_soname编译选项是需要的。当然，-share选项更不能丢。

    (2) 安装使用共享库
    一旦你创建好共享库后就需要安装使用了，最简单的办法是将库拷贝到默认目录下(/usr/lib)。
    然后创建一些符号链接，最简单的方式还是使用ldconfig(8)来处理这里符号链接。最后是重新
    编译链接你的程序,通过-L和-l参数指定库路径就可以了。

三、动态加载库
1. 概念
   动态加载库(dynamically loaded (DL) libraries)是指在程序运行过程中可以加载的函数库。
   而不是像共享库一样在程序启动的时候加载。DL对于实现插件和模块非常有用，因为他们可以让程序
在允许时等待插件的加载。在Linux中，动态库的文件格式跟共享库没有区别，主要区别在于共享库是运行时加载。
   有专门的一组API用于完成打开动态库，查找符号，
   处理出错，关闭动态库等功能。

   下面对这些接口函数逐一介绍:
   (1) dlopen
   函数原型：void *dlopen(const char *libname,int flag);
   功能描述：dlopen必须在dlerror，dlsym和dlclose之前调用，表示要将库装载到内存，准备使用。
   如果要装载的库依赖于其它库，必须首先装载依赖库。如果dlopen操作失败，返回NULL值；如果库已经
   被装载过，则dlopen会返回同样的句柄。
   参数中的libname一般是库的全路径，这样dlopen会直接装载该文件；如果只是指定了库名称，在dlopen
   会按照下面的机制去搜寻：
       a.根据环境变量LD_LIBRARY_PATH查找
       b.根据/etc/ld.so.cache查找
       c.查找依次在/lib和/usr/lib目录查找。
   flag参数表示处理未定义函数的方式，可以使用RTLD_LAZY或RTLD_NOW。RTLD_LAZY表示暂时不去
   处理未定义函数，先把库装载到内存，等用到没定义的函数再说；RTLD_NOW表示马上检查是否存在未定义
   的函数，若存在，则dlopen以失败告终。

   (2) dlerror
   函数原型：char *dlerror(void);
   功能描述：dlerror可以获得最近一次dlopen,dlsym或dlclose操作的错误信息，返回NULL表示
   无错误。dlerror在返回错误信息的同时，也会清除错误信息。

   (3) dlsym
   函数原型：void *dlsym(void *handle,const char *symbol);
   功能描述：在dlopen之后，库被装载到内存。dlsym可以获得指定函数(symbol)在内存中的位置(指针)。
   如果找不到指定函数，则dlsym会返回NULL值。但判断函数是否存在最好的方法是使用dlerror函数，

   (4) dlclose
   函数原型：int dlclose(void *);
   功能描述：将已经装载的库句柄减一，如果句柄减至零，则该库会被卸载。如果存在析构函数，则在dlclose
   之后，析构函数会被调用。

2. 使用实例
    $cat dltest.c
    #include <stdlib.h>
    #include <stdio.h>
    #include <dlfcn.h>

    int main(int argc, char **argv)
    {
        void *handle;
        double (*cosine)(double);
        char *error;

        handle = dlopen ("/lib/libm.so.6", RTLD_LAZY);
        if (!handle) {
            fputs (dlerror(), stderr);
            exit(1);
        }

        cosine = dlsym(handle, "cos");
        if ((error = dlerror()) != NULL) {
            fputs(error, stderr);
            exit(1);
        }

        printf ("%f\n", (*cosine)(2.0));
        dlclose(handle);
        return 0;

    }


    编译: $ gcc -o dltest dltest.c -ldl -Wall
    运行: $ ./dltest
         -0.416147

四、其他
(1) nm命令可以查可能一个库中的符号

结束！！！

两个要知道的基本知识

Linux 应用程序因为 Linux 版本的众多与各自独立性，在工程制作与使用中必须熟练掌握如下两点才能有效地工作和理想地运行。

Linux 下标准库链接的三种方式（全静态 , 半静态 (libgcc,libstdc++), 全动态）及其各自利弊。
Linux 下如何巧妙构建 achrive(*.a)，并且如何设置链接选项来解决 gcc 比较特别的链接库的顺序问题。

三种标准库链接方式选项及对比

为了演示三种不同的标准库链接方式对最终应用程序产生的区别，这里用了一个经典的示例应用程序 HelloWorld 做演示，见清单 1 HelloWorld。整个工程可以在文章末尾下载。

清单 1. HelloWorld

				
 #include <stdio.h> 
 #include <iostream> 
 using std::cout; 
 using std::endl; 


 int main(int argc, char* argv[]) 
 { 
  printf("HelloWorld!(Printed by printf)\n"); 

  cout<<"HelloWorld!(Printed by cout)"<<endl; 

  return 0; 
 }

三种标准库链接方式的选项及区别见表 1

表 1. 三种标准库链接方式的选项及区别

标准库连接方式	示例连接选项	优点	缺点
全静态	-static -pthread -lrt -ldl	不会发生应用程序在不同 Linux 版本下的标准库不兼容问题。	生成的文件比较大，应用程序功能受限（不能调用动态库等）
全动态	-pthread -lrt -ldl	生成文件是三者中最小的	比较容易发生应用程序在不同 Linux 版本下标准库依赖不兼容问题。
半静态 (libgcc,libstdc++)	-static-libgcc -L. -pthread -lrt -ldl	灵活度大，能够针对不同的标准库采取不同的链接策略，从而避免不兼容问题发生。结合了全静态与全动态两种链接方式的优点。	比较难识别哪些库容易发生不兼容问题，目前只有依靠经验积累。某些功能会因选择的标准库版本而丧失。

上述三种标准库链接方式中，比较特殊的是 半静态链接方式，主要在于其还需要在链接前增加额外的一个步骤：
ln -s `g++ -print-file-name=libstdc++.a`，作用是将 libstdc++.a（libstdc++ 的静态库）符号链接到本地工程链接目录。
-print-file-name 在 gcc 中的解释如下：
-print-file-name=<lib> Display the full path to library <lib>

为了区分三种不同的标准库链接方式对最终生成的可执行文件的影响，本文从两个不同的维度进行分析比较：

维度一：最终生成的可执行文件对标准库的依赖方式（使用 ldd 命令进行分析）

ldd 简介：该命令用于打印出某个应用程序或者动态库所依赖的动态库
涉及语法：ldd [OPTION]... FILE...
其他详细说明请参阅 man 说明。

三种标准库链接方式最终产生的应用程序的可执行文件对于标准库的依赖方式具体差异见图 1、图 2、图 3所示：

图 1. 全静态标准库链接方式

图 2. 全动态标准库链接方式

图 3. 半静态（libgcc,libstdc++) 标准库链接方式

通过上述三图，可以清楚的看到，当用 全静态标准库的链接方式时，所生成的可执行文件最终不依赖任何的动态标准库，
而 全动态标准库的链接方式会导致最终应用程序可执行文件依赖于所有用到的标准动态库。
区别于上述两种方式的 半静态链接方式则有针对性的将 libgcc 和 libstdc++ 两个标准库非动态链接。
（对比图 2与图 3，可见在图 3中这两个标准库的动态依赖不见了）

从实际应用当中发现，最理想的标准库链接方式就是半静态链接，通常会选择将 libgcc 与 libstdc++ 这两个标准库静态链接，
从而避免应用程序在不同 Linux 版本间标准库依赖不兼容的问题发生。

维度二 : 最终生成的可执行文件大小（使用 size 命令进行分析）

size 简介：该命令用于显示出可执行文件的大小
涉及语法：size objfile...
其他详细说明请参阅 man 说明。

三种标准库链接方式最终产生的应用程序的可执行文件的大小具体差异见图 4、图 5、图 6所示：

图 4. 全静态标准库链接方式

图 5. 全动态标准库链接方式

图 6. 半静态（libgcc,libstdc++) 标准库链接方式

通过上述三图可以看出，最终可执行文件的大小随最终所依赖的标准动态库的数量增加而减小。
从实际应用当中发现，最理想的是 半静态链接方式，因为该方式能够在避免应用程序于
不同 Linux 版本间标准库依赖不兼容的问题发生的同时，使最终生成的可执行文件大小最小化。

示例链接选项中所涉及命令（引用 GCC 原文）：

-llibrary
-l library：指定所需要的额外库
-Ldir：指定库搜索路径
-static：静态链接所有库
-static-libgcc：静态链接 gcc 库
-static-libstdc++：静态链接 c++ 库
关于上述命令的详细说明，请参阅 GCC 技术手册

回页首

Linux 下静态库（archive）的制作方式：

涉及命令：ar

ar 简介：处理创建、修改、提取静态库的操作

涉及选项：
t - 显示静态库的内容
r[ab][f][u] - 更新或增加新文件到静态库中
[s] - 创建文档索引
ar -M [<mri-script] - 使用 ar 脚本处理
其他详细说明请参阅 man 说明。

示例情景：

假设现有如图 7所示两个库文件

图 7. 示例静态库文件

从图 7中可以得知，CdtLog.a 只包含 CdtLog.o 一个对象文件 , 而 xml.a 包含 TXmlParser.o 和 xmlparser.o 两个对象文件
现将 CdtLog.o 提取出来，然后通过图 8方式创建一个新的静态库 demo.a，可以看出，demo.a 包含的是 CdtLog.o 以及 xml.a，
而不是我们所预期的 CdtLog.o,TXmlParser.o 和 xmlparser.o。这正是区别于 Windows 下静态库的制作。

图 8. 示例静态库制作方式 1

这样的 demo.a 当被链接入某个工程时，所有在 TXmlParser.o 和 xmlparser.o 定义的符号都不会被发现，从而会导致链接错误，
提示无法找到对应的符号。显然，通过图 8 方式创建 Linux 静态库是不正确的。

正确的方式有两种：

将所有静态库中包含的对象文件提取出来然后重新打包成新的静态库文件。
用一种更加灵活的方式创建新的静态库文件：ar 脚本。

显然，方式 1 是比较麻烦的，因为涉及到太多的文件处理，可能还要通过不断创建临时目录用于保存中间文件。
推荐使用如清单 2 createlib.sh所示的 ar 脚本方式进行创建：

清单 2 createlib.sh

				
 rm demo.a 
 rm ar.mac 
 echo CREATE demo.a > ar.mac 
 echo SAVE >> ar.mac 
 echo END >> ar.mac 
 ar -M < ar.mac 
 ar -q demo.a CdtLog.o 
 echo OPEN demo.a > ar.mac 
 echo ADDLIB xml.a >> ar.mac 
 echo SAVE >> ar.mac 
 echo END >> ar.mac 
 ar -M < ar.mac 
 rm ar.mac

如果想在 Linux makefile 中使用 ar 脚本方式进行静态库的创建，可以编写如清单 3 BUILD_LIBRARY所示的代码：

清单 3 BUILD_LIBRARY

				
 define BUILD_LIBRARY 
 $(if $(wildcard $@),@$(RM) $@) 
 $(if $(wildcard ar.mac),@$(RM) ar.mac) 
 $(if $(filter %.a, $^), 
 @echo CREATE $@ > ar.mac 
 @echo SAVE >> ar.mac 
 @echo END >> ar.mac 
 @$(AR) -M < ar.mac 
 ) 
 $(if $(filter %.o,$^),@$(AR) -q $@ $(filter %.o, $^)) 
 $(if $(filter %.a, $^), 
 @echo OPEN $@ > ar.mac 
 $(foreach LIB, $(filter %.a, $^), 
 @echo ADDLIB $(LIB) >> ar.mac 
 ) 
 @echo SAVE >> ar.mac 
 @echo END >> ar.mac 
 @$(AR) -M < ar.mac 
 @$(RM) ar.mac 
 ) 
 endef 

 $(TargetDir)/$(TargetFileName):$(OBJS) 
    $(BUILD_LIBRARY)

通过图 9，我们可以看到，用这种方式产生的 demo.a 才是我们想要的结果。

图 9. 巧妙创建的静态库文件结果

回页首

Linux 静态库链接顺序问题及解决方法：

正如 GCC 手册中提到的那样：
It makes a difference where in the command you write this option; the linker
searches and processes libraries and object files in the order they are specified.
Thus, ‘ foo.o -lz bar.o ’ searches library ‘ z ’ after file ‘ foo.o ’ but before
‘ bar.o ’ . If ‘ bar.o ’ refers to functions in ‘ z ’ , those functions may not be loaded.

为了解决这种库链接顺序问题，我们需要增加一些链接选项 :

$(CXX) $(LINKFLAGS) $(OBJS) -Xlinker "-(" $(LIBS) -Xlinker "-)" -o $@

通过将所有需要被链接的静态库放入 -Xlinker "-(" 与 -Xlinker "-)" 之间，可以是 g++ 链接过程中，自动循环链接所有静态库，从而解决了原本的链接顺序问题。

涉及链接选项：-Xlinker

-Xlinker option
Pass option as an option to the linker. You can use this to supply system-specific
linker options which GCC does not know how to recognize.

编译-链接-生成是众所周知的三部曲，所谓动态、静态都是链接这一步上的花头，举个我觉得还算形象的比喻就是：

动态库和静态库之于应用程序的区别就好比银行卡和现金之于消费者一样。消费者（app）需要用钱（invoke）时，如果有现金（.a），就可以直接用；否则，就得用银行卡去银行（.so）刷卡取钱。带着现金会让钱包很鼓，但消费者（app）可以很方便地使用。而银行卡(.so)只是薄薄一张卡片，加载很容易，但使用时要多绕一步，并存在刷不上钱的杯具(cannot open shared object file)。

我们试着把这个例子变成代码，首先定义

money.h:

 
   1#ifndef MONEY_H
 
   2#define MONEY
 
   3void showmethemoney(intmoney);
 
   4#endif

money.c:

 
   1#include <stdio.h>
 
   2void showmethemoney(intmoney){
 
   3    printf("$%d\n",money);
 
   4}

接下来，分别把money搞成现金和银行卡。但无论怎样，link之前的compile，即编译成.o文件是必需的。

编译.c 为 .o

 
   1[root@backup kongch]# ls
 
   2money.c  money.h
 
   3[root@backup kongch]# gcc -c money.c
 
   4[root@backup kongch]# ls
 
   5money.c  money.h  money.o

编译.o 为 .a

静态库文件名的命名规范是以lib为前缀，紧接着跟静态库名，扩展名为.a。
我们将创建的静态库名为cash，则静态库文件名就是libcash.a。在创建和使用静态库时，需要注意这点。创建静态库用ar命令:

 
   1[root@backup kongch]# ls
 
   2money.c  money.h  money.o
 
   3[root@backup kongch]# ar crv libcash.a  money.o
 
   4a - money.o
 
   5[root@backup kongch]# ls
 
   6libcash.a  money.c  money.h  money.o

编译.o 为 .so

动态库文件名命名规范和静态库文件名命名规范类似，也是在动态库名增加前缀lib，但其文件扩展名为.so。
我们将创建的动态库名为bank，则动态库文件就是libbank.so。用gcc来生成动态库：

 
   1[root@backup kongch]# gcc -shared -fPIC -o libbank.so money.o
 
   2/usr/bin/ld: money.o: relocation R_X86_64_32 against `alocal symbol' can not be used when making a shared object; recompile with -fPIC
 
   3money.o: could not readsymbols: Bad value
 
   4collect2: ld returned 1 exitstatus

我在CentOS 5.3 x85_64上得到了这样的错误，至于错误原因及什么是fPIC，参见这里。我们先fix这个问题再说——在编译.o的过程中使用-fPIC参数：

 
   1[root@backup kongch]# gcc -c -fPIC money.c
 
   2[root@backup kongch]# gcc -shared -fPIC -o libbank.so money.o
 
   3[root@backup kongch]# ls -la
 
   4total 32
 
   5drwx------ 2 root root 4096 Nov  1 15:04 .
 
   6drwx------ 3 root root 4096 Nov  1 14:53 ..
 
   7-rwx------ 1 root root 5848 Nov  1 15:04 libbank.so
 
   8-rw------- 1 root root 1656 Nov  1 14:56 libcash.a
 
   9-rw------- 1 root root   79 Nov  1 14:41 money.c
 
   10-rw------- 1 root root   69 Nov  1 14:38 money.h
 
   11-rw------- 1 root root 1552 Nov  1 15:04 money.o

可以看到我们有了libcash.a和libbank.so，万事俱备，只欠东风。东风就是搞段代码来调用showmethemoney.

main.c

 
   1#include "money.h"
 
   2 
 
   3int main(){
 
   4    showmethemoney(100);
 
   5    return0;
 
   6}

静态链接

告诉gcc静态链接库在哪里就可以了：

 
   1[root@backup kongch]# gcc -o cash main.c -L. -lcash
 
   2$100
 
   3[root@backup kongch]# ls -la
 
   4total 44
 
   5drwx------ 2 root root 4096 Nov  1 15:11 .
 
   6drwx------ 3 root root 4096 Nov  1 14:53 ..
 
   7-rwx------ 1 root root 6879 Nov  1 15:11 cash
 
   8-rwx------ 1 root root 5848 Nov  1 15:04 libbank.so
 
   9-rw------- 1 root root 1656 Nov  1 14:56 libcash.a
 
   10-rw------- 1 root root   73 Nov  1 15:10 main.c
 
   11-rw------- 1 root root   79 Nov  1 14:41 money.c
 
   12-rw------- 1 root root   69 Nov  1 14:38 money.h
 
   13-rw------- 1 root root 1552 Nov  1 15:04 money.o

执行cash：

 
   1[root@backup kongch]# ./cash
 
   2$100

我们注意到cash的文件大小是6879字节。

动态链接

方式几乎与静态链接一样，为了区别，我们把动态链接的输出叫做bank。

 
   1[root@backup kongch]# gcc -o bank main.c -L. -lbank
 
   2[root@backup kongch]# ls -la
 
   3total 52
 
   4drwx------ 2 root root 4096 Nov  1 15:15 .
 
   5drwx------ 3 root root 4096 Nov  1 14:53 ..
 
   6-rwx------ 1 root root 6955 Nov  1 15:15 bank
 
   7-rwx------ 1 root root 6879 Nov  1 15:11 cash
 
   8-rwx------ 1 root root 5848 Nov  1 15:04 libbank.so
 
   9-rw------- 1 root root 1656 Nov  1 14:56 libcash.a
 
   10-rw------- 1 root root   73 Nov  1 15:10 main.c
 
   11-rw------- 1 root root   79 Nov  1 14:41 money.c
 
   12-rw------- 1 root root   69 Nov  1 14:38 money.h
 
   13-rw------- 1 root root 1552 Nov  1 15:04 money.o

我们注意到动态链接的bank并不比静态链接的cash小，这好像跟前面提到的鼓钱包论矛盾了。个人猜测是我们的money.o太过简单，只有一个showmethemoney函数，体现不出.so的优势来。

试着执行一下bank：

 
   1[root@backup kongch]# ./bank
 
   2./bank: error whileloading shared libraries: libbank.so: cannot openshared object  file: No suchfile or directory

失败了。这就需要我们搞清楚动态链接、执行时搜索路径顺序:

编译目标代码时指定的动态库搜索路径；
环境变量LD_LIBRARY_PATH指定的动态库搜索路径；
配置文件/etc/ld.so.conf中指定的动态库搜索路径；
默认的动态库搜索路径/lib；
默认的动态库搜索路径/usr/lib。

我们通过2、3两种方式来让我们的bank正常：

方式2

在执行前手动指定so所在路径，但就像你知道的，这样的指定是seesion级别的，每次执行都要这么来：

 
   1[root@backup kongch]# LD_LIBRARY_PATH=. ./bank
 
   2$100

方式3

手动指定/etc/ld.so.conf里包含的路径，比如我的测试server上

 
   1[root@backup kongch]# cat /etc/ld.so.conf
 
   2include ld.so.conf.d/*.conf

那我就可以创建一个自己的conf：/etc/ld.so.conf.d/kong.conf，文件内容就是当前libbank.so所在目录：/home/kongch/
下来要记得ldconfig，这样bank就可以工作了：

 
   1[root@backup kongch]# ldconfig
 
   2[root@backup kongch]# ./bank
 
   3$100

这种方式一劳永逸，不过需要有root权限。

废话这么多，只是因为好记性不如烂笔头。更详细，更准确的使用和描述，还是参见这里吧。

http://www.cnblogs.com/feisky/archive/2010/03/09/1681996.html

http://blog.csdn.net/ast_224/article/details/3988244

来源：http://blog.csdn.net/yusiguyuan/article/details/12744705

jsj020122

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
linux下静态库和动态库的创建

linux静态链接库与动态链接库的区别及动态库的创建一、引言通常情况下，对函数库的链接是放在编译时期（compile time）完成的。所有相关的对象文件（object file）与牵涉到的函数库（library）被链接合成一个可执行文件（executable file）。程序在运行时，与函数库再无瓜葛，因为所有需要的函数已拷贝到自己门下。所以这些函数库被成为静态库（static
复制链接

扫一扫