[转+整理]关于linux静态库和动态库的分析

最新推荐文章于 2023-05-20 10:00:00 发布

newchenxf

最新推荐文章于 2023-05-20 10:00:00 发布

阅读量1.2k

点赞数 1

分类专栏：编译处理文章标签：静态库动态库

编译处理专栏收录该内容

4 篇文章 1 订阅

订阅专栏

本想写一篇和静态库/动态库有关的文章，但看到网上有个人写的已经很好，故而转发吧。^^，不过原文写的有些重复，我稍微做了一下整理。
原文网址：http://blog.chinaunix.net/uid-27200305-id-3313635.html

此外，有个复杂点的问题：
一个静态库libAAA.a，用了系统的动态库，libpthread.so，现在有个程序main.c，用了libAAA.a，那此时main链接的时候，需不需要链接libpthread.so?为此我写了一篇文章：

一问一答

1.什么是库

在windows平台和linux平台下都大量存在着库。
本质上来说库是一种可执行代码的二进制形式，可以被操作系统载入内存执行。
由于windows和linux的本质不同，因此二者库的二进制是不兼容的。
本文仅限于介绍linux下的库。

2.库的种类

linux下的库有两种：静态库和共享库（动态库）。动态通常用.so为后缀，静态用.a为后缀。
例如：libhello.so libhello.a 为了在同一系统中使用不同版本的库，可以在库文件名后加上版本号为后缀,例如： libhello.so.1.0,由于程序连接默认以.so为文件后缀名。所以为了使用这些库，通常使用建立符号连接的方式。
ln -s libhello.so.1.0 libhello.so.1
ln -s libhello.so.1 libhello.so

二者的不同点在于代码被载入的时刻不同。
静态库的代码在编译过程中已经被载入可执行程序，因此体积较大。
共享库的代码是在可执行程序运行时才载入内存的，在编译过程中仅简单的引用，因此代码体积较小。

3.库存在的意义

库是别人写好的现有的，成熟的，可以复用的代码，你可以使用但要记得遵守许可协议。
现实中每个程序都要依赖很多基础的底层库，不可能每个人的代码都从零开始，因此库的存在意义非同寻常。
共享库的好处是，不同的应用程序如果调用相同的库，那么在内存里只需要有一份该共享库的实例。

4.库文件是如何产生的在linux下

静态库的后缀是.a，它的产生分两步
Step 1.由源文件编译生成一堆.o，每个.o里都包含这个编译单元的符号表
Step 2.ar命令将很多.o转换成.a，成文静态库
动态库的后缀是.so，它由gcc加特定参数编译产生。
例如:

$gcc -fPIC -c *.c$ gcc -shared -Wl,-soname, libfoo.so.1 -o libfoo.so.1.0 *.

5.库文件是如何命名的，有没有什么规范

在linux下，库文件一般放在/usr/lib /lib下，
静态库的名字一般为libxxxx.a，其中xxxx是该lib的名称
动态库的名字一般为libxxxx.so.major.minor，xxxx是该lib的名称，major是主版本号， minor是副版本号

6.如何知道一个可执行程序依赖哪些库

ldd命令可以查看一个可执行程序依赖的共享库，
例如# ldd /bin/lnlibc.so.6
=> /lib/libc.so.6 (0×40021000)/lib/ld-linux.so.2
=> /lib/ld- linux.so.2 (0×40000000)
可以看到ln命令依赖于libc库和ld-linux库

7.可执行程序在执行的时候如何定位共享库文件

当系统加载可执行代码时候，能够知道其所依赖的库的名字，但是还需要知道绝对路径
此时就需要系统动态载入器(dynamic linker/loader)
对于elf格式的可执行程序，是由ld-linux.so*来完成的，它先后搜索elf文件的 DT_RPATH段—环境变量LD_LIBRARY_PATH—/etc/ld.so.cache文件列表—/lib/,/usr/lib目录找到库文件后将其载入内存

8.在新安装一个库之后如何让系统能够找到他

如果安装在/lib或者/usr/lib下，那么ld默认能够找到，无需其他操作。
如果安装在其他目录，需要将其添加到/etc/ld.so.cache文件中，步骤如下
1.编辑/etc/ld.so.conf文件，加入库文件所在目录的路径
2.运行ldconfig，该命令会重建/etc/ld.so.cache文件

9.动态库的路径问题

为了让执行程序顺利的找到动态库，有三种方法：
(1) 把库拷贝到/usr/lib和/lib目录下。
(2) 在LD_LIBRARY_PATH环境变量中加上库所在路径。
(3) 添加/etc/ld.so.conf.d/*.conf文件，把库所在路径加到文件末尾，并执行ldconfig刷新。
这样，加入的目录下的所有库都可见。

10.LD_LIBRARY_PATH环境变量的设置

Linux环境变量名，该环境变量主要用于指定查找共享库（动态链接库）时除了默认路径之外的其他路径。(该路径在默认路径之前查找)
移植程序时的经常碰到需要使用一些特定的动态库，而这些编译好的动态库放在我们自己建立的目录里，这时可以将这些目录设置到LD_LIBRARY_PATH中。
(1)在linux下可以用export命令来设置这个值，
在linux终端下输入:

export LD_LIBRARY_PATH=/opt/au1200_rm/build_tools/bin: $LD_LIBRARY_PATH:

然后再输入:

export

即会显示是否设置正确
export方式在重启后失效.

(2)也可以用 vim /etc/bashrc ，修改其中的LD_LIBRARY_PATH变量。
例如：LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/au1200_rm/build_tools/bin。

11. 查看库中的符号：nm命令

有时候可能需要查看一个库中到底有哪些函数，nm命令可以打印出库中的涉及到的所有符号。库既可以是静态的也可以是动态的。nm列出的符号有很多，常见的有三种：
一种是在库中被调用，但并没有在库中定义(表明需要其他库支持)，用U表示；
一种是库中定义的函数，用T表示，这是最常见的；
另外一种是所谓的“弱态”符号，它们虽然在库中被定义，但是可能被其他库中的同名符号覆盖，用W表示。

例子：

chenxf@chenxf-PC:~/static_lib_sample$ nm libstatic_lib_example.a

static_lib_example.o:
                 U fwrite
                 U printf
                 U pthread_create
                 U pthread_join
                 U puts
                 U stderr
0000000000000040 T testFunc
0000000000000000 T thread_exe

意味着pthread_create，pthread_join等函数，还依赖于别的库（libpthread.so）。

12. 查看库的符号：objdump命令

这部分由小编我添加
objdump也可以查看库的符号，动态库，静态库都可以看。

动态库：

objdump –syms libstatic_lib_example.so

结果：

chenxf@chenxf-PC:~/static_lib_sample$ objdump --syms libstatic_lib_example.so

libstatic_lib_example.so：     文件格式 elf64-x86-64

SYMBOL TABLE:
00000000000001c8 l    d  .note.gnu.build-id     0000000000000000              .note.gnu.build-id
00000000000001f0 l    d  .gnu.hash      0000000000000000              .gnu.hash
0000000000000230 l    d  .dynsym        0000000000000000              .dynsym
0000000000000410 l    d  .dynstr        0000000000000000              .dynstr
00000000000004fe l    d  .gnu.version   0000000000000000              .gnu.version
0000000000000528 l    d  .gnu.version_r 0000000000000000              .gnu.version_r
0000000000000548 l    d  .rela.dyn      0000000000000000              .rela.dyn
0000000000000638 l    d  .rela.plt      0000000000000000              .rela.plt
00000000000006e0 l    d  .init  0000000000000000              .init
0000000000000700 l    d  .plt   0000000000000000              .plt
0000000000000780 l    d  .text  0000000000000000              .text
0000000000000998 l    d  .fini  0000000000000000              .fini
00000000000009a1 l    d  .rodata        0000000000000000              .rodata
0000000000000a14 l    d  .eh_frame_hdr  0000000000000000              .eh_frame_hdr
0000000000000a38 l    d  .eh_frame      0000000000000000              .eh_frame
0000000000200df0 l    d  .init_array    0000000000000000              .init_array
0000000000200df8 l    d  .fini_array    0000000000000000              .fini_array
0000000000200e00 l    d  .jcr   0000000000000000              .jcr
0000000000200e08 l    d  .dynamic       0000000000000000              .dynamic
0000000000200fc8 l    d  .got   0000000000000000              .got
0000000000201000 l    d  .got.plt       0000000000000000              .got.plt
0000000000201050 l    d  .data  0000000000000000              .data
0000000000201058 l    d  .bss   0000000000000000              .bss
0000000000000000 l    d  .comment       0000000000000000              .comment
0000000000000000 l    df *ABS*  0000000000000000              crtstuff.c
0000000000200e00 l     O .jcr   0000000000000000              __JCR_LIST__
0000000000000780 l     F .text  0000000000000000              deregister_tm_clones
00000000000007b0 l     F .text  0000000000000000              register_tm_clones
00000000000007f0 l     F .text  0000000000000000              __do_global_dtors_aux
0000000000201058 l     O .bss   0000000000000001              completed.6973
0000000000200df8 l     O .fini_array    0000000000000000              __do_global_dtors_aux_fini_array_entry
0000000000000830 l     F .text  0000000000000000              frame_dummy
0000000000200df0 l     O .init_array    0000000000000000              __frame_dummy_init_array_entry
0000000000000000 l    df *ABS*  0000000000000000              static_lib_example.c
0000000000000000 l    df *ABS*  0000000000000000              crtstuff.c
0000000000000ab8 l     O .eh_frame      0000000000000000              __FRAME_END__
0000000000200e00 l     O .jcr   0000000000000000              __JCR_END__
0000000000000000 l    df *ABS*  0000000000000000
0000000000201050 l     O .data  0000000000000000              __dso_handle
0000000000200e08 l     O .dynamic       0000000000000000              _DYNAMIC
0000000000201058 l     O .data  0000000000000000              __TMC_END__
0000000000201000 l     O .got.plt       0000000000000000              _GLOBAL_OFFSET_TABLE_
0000000000000000  w      *UND*  0000000000000000              _ITM_deregisterTMCloneTable
0000000000000000       F *UND*  0000000000000000              puts@@GLIBC_2.2.5
00000000000008a7 g     F .text  00000000000000f1              testFunc
0000000000201058 g       .data  0000000000000000              _edata
0000000000000998 g     F .fini  0000000000000000              _fini
0000000000000000       F *UND*  0000000000000000              printf@@GLIBC_2.2.5
0000000000000000  w      *UND*  0000000000000000              __gmon_start__
0000000000201060 g       .bss   0000000000000000              _end
0000000000000865 g     F .text  0000000000000042              thread_exe
0000000000201058 g       .bss   0000000000000000              __bss_start
0000000000000000         *UND*  0000000000000000              pthread_join
0000000000000000         *UND*  0000000000000000              pthread_create
0000000000000000  w      *UND*  0000000000000000              _Jv_RegisterClasses
0000000000000000       F *UND*  0000000000000000              fwrite@@GLIBC_2.2.5
0000000000000000  w      *UND*  0000000000000000              _ITM_registerTMCloneTable
0000000000000000  w    F *UND*  0000000000000000              __cxa_finalize@@GLIBC_2.2.5
00000000000006e0 g     F .init  0000000000000000              _init
0000000000000000       O *UND*  0000000000000000              stderr@@GLIBC_2.2.5

静态库：

objdump –syms libstatic_lib_example.a

结果：

chenxf@chenxf-PC:~/static_lib_sample$ objdump --syms libstatic_lib_example.a
在归档文件 libstatic_lib_example.a 中：

static_lib_example.o：     文件格式 elf64-x86-64

SYMBOL TABLE:
0000000000000000 l    df *ABS*  0000000000000000 static_lib_example.c
0000000000000000 l    d  .text  0000000000000000 .text
0000000000000000 l    d  .data  0000000000000000 .data
0000000000000000 l    d  .bss   0000000000000000 .bss
0000000000000000 l    d  .rodata        0000000000000000 .rodata
0000000000000000 l    d  .note.GNU-stack        0000000000000000 .note.GNU-stack
0000000000000000 l    d  .eh_frame      0000000000000000 .eh_frame
0000000000000000 l    d  .comment       0000000000000000 .comment
0000000000000000 g     F .text  0000000000000040 thread_exe
0000000000000000         *UND*  0000000000000000 puts
0000000000000040 g     F .text  00000000000000df testFunc
0000000000000000         *UND*  0000000000000000 printf
0000000000000000         *UND*  0000000000000000 pthread_create
0000000000000000         *UND*  0000000000000000 stderr
0000000000000000         *UND*  0000000000000000 fwrite
0000000000000000         *UND*  0000000000000000 pthread_join

13. 查看一个程序都依赖于哪些动态库：ldd命令

这部分由小编我添加
首先，程序编译好后，不会再依赖静态库，因为静态库本身就不能被动态加载。程序已经把静态库的东西，全部吸收了。

例子：

chenxf@chenxf-PC:~/test_main$ ldd test_main
        linux-vdso.so.1 =>  (0x00007ffec5f7d000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f72f84b9000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f72f80f4000)
        /lib64/ld-linux-x86-64.so.2 (0x000055f292c51000)

静态库与动态库使用实例

我们通常把一些公用函数制作成函数库，供其它程序使用。函数库分为静态库和动态库两种。静态库在程序编译时会被连接到目标代码中，程序运行时将不再需要该静态库。动态库在程序编译时并不会被连接到目标代码中，而是在程序运行是才被载入，因此在程序运行时还需要动态库存在。本文主要通过举例来说明在Linux中如何创建静态库和动态库，以及使用它们。在创建函数库前，我们先来准备举例用的源程序，并将函数库的源程序编译成.o文件。

第1步：编辑得到举例的程序–hello.h、hello.c和main.c；

hello.h(见程序1)为该函数库的头文件。
hello.c(见程序2)是函数库的源程序，其中包含公用函数hello，该函数将在屏幕上输出”Hello XXX!”。
main.c(见程序3)为测试库文件的主程序，在主程序中调用了公用函数hello。


 程序1: hello.h
 #ifndef HELLO_H
 #define HELLO_H

 void hello(const char *name);

 #endif //HELLO_H

 程序2: hello.c

 #include 

 void hello(const char *name)
 {
  printf("Hello %s!\n", name);
 }


  程序3: main.c
 #include "hello.h"

 int main()
 {
  hello("everyone");
  return 0;
 }

第2步：将hello.c编译成.o文件；

无论静态库，还是动态库，都是由.o文件创建的。因此，我们必须将源程序hello.c通过gcc先编译成.o文件。
在系统提示符下键入以下命令得到hello.o文件。

gcc -c hello.c

(注1：本文不介绍各命令使用和其参数功能，若希望详细了解它们，请参考其他文档。)
(注2：首字符”#”是系统提示符，不需要键入，下文相同。)
我们运行ls命令看看是否生存了hello.o文件。

$ ls

$ hello.c hello.h hello.o main.c

在ls命令结果中，我们看到了hello.o文件，本步操作完成。
下面我们先来看看如何创建静态库，以及使用它。

第3步：由.o文件创建静态库；（ar命令）

静态库文件名的命名规范是以lib为前缀，紧接着跟静态库名，扩展名为.a。例如：我们将创建的静态库名为myhello，则静态库文件名就是libmyhello.a。在创建和使用静态库时，需要注意这点。创建静态库用ar命令。
在系统提示符下键入以下命令将创建静态库文件libmyhello.a。

$ ar cr libmyhello.a hello.o

我们同样运行ls命令查看结果：

$ ls

$ hello.c hello.h hello.o libmyhello.a main.c

ls命令结果中有libmyhello.a。

第4步：在程序中使用静态库；

静态库制作完了，如何使用它内部的函数呢？只需要在使用到这些公用函数的源程序中包含这些公用函数的原型声明，然后在用gcc命令生成目标文件时指明静态库名，gcc将会从静态库中将公用函数连接到目标文件中。注意，gcc会在静态库名前加上前缀lib，然后追加扩展名.a得到的静态库文件名来查找静态库文件。
在程序3:main.c中，我们包含了静态库的头文件hello.h，然后在主程序main中直接调用公用函数hello。下面先生成目标程序hello，然后运行hello程序看看结果如何。

$ gcc -o hello main.c -L. -lmyhello

$ ./hello

$ Hello everyone!

我们删除静态库文件试试公用函数hello是否真的连接到目标文件 hello中了。

$ rm libmyhello.a

$ rm: remove regular file `libmyhello.a’? y

$ ./hello

$ Hello everyone!

程序照常运行，静态库中的公用函数已经连接到目标文件中了。
我们继续看看如何在Linux中创建动态库。我们还是从.o文件开始。

第5步：由.o文件创建动态库文件；（gcc -shared -fPIC）

动态库文件名命名规范和静态库文件名命名规范类似，也是在动态库名增加前缀lib，但其文件扩展名为.so。例如：我们将创建的动态库名为myhello，则动态库文件名就是libmyhello.so。用gcc来创建动态库。
在系统提示符下键入以下命令得到动态库文件libmyhello.so。

gcc -shared -fPIC -o libmyhello.so hello.o

gcc -shared 参数使其生成是动态库而不是普通执行程序。

我们照样使用ls命令看看动态库文件是否生成。

$ls

$ hello.c hello.h hello.o libmyhello.so main.c

第6步：在程序中使用动态库；

在程序中使用动态库和使用静态库完全一样，也是在使用到这些公用函数的源程序中包含这些公用函数的原型声明，然后在用gcc命令生成目标文件时指明动态库名进行编译。我们先运行gcc命令生成目标文件，再运行它看看结果。

$ gcc -o hello main.c -L. -lmyhello

$ ./hello

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

哦！出错了。快看看错误提示，原来是找不到动态库文件libmyhello.so。程序在运行时，会在/usr/lib和/lib等目录中查找需要的动态库文件。若找到，则载入动态库，否则将提示类似上述错误而终止程序运行。我们将文件libmyhello.so复制到目录/usr/lib中，再试试。

$ mv libmyhello.so /usr/lib

$ ./hello

$./hello: error while loading shared libraries: /usr/lib/libhello.so: cannot restore segment prot after reloc: Permission denied

由于SELinux引起，

$chcon -t texrel_shlib_t /usr/lib/libhello.so

$ ./hello

$ Hello everyone!

成功了。这也进一步说明了动态库在程序运行时是需要的。
我们回过头看看，发现使用静态库和使用动态库编译成目标程序使用的gcc命令完全一样，那当静态库和动态库同名时，gcc命令会使用哪个库文件呢？抱着对问题必究到底的心情，来试试看。
先删除除.c和.h外的所有文件，恢复成我们刚刚编辑完举例程序状态。

$ rm -f hello hello.o /usr/lib/libmyhello.so

$ ls

$hello.c hello.h main.c

在来创建静态库文件libmyhello.a和动态库文件libmyhello.so。

$ gcc -c hello.c

$ ar cr libmyhello.a hello.o

$ gcc -shared -fPIC -o libmyhello.so hello.o

$ ls

$hello.c hello.h hello.o libmyhello.a libmyhello.so main.c

通过上述最后一条ls命令，可以发现静态库文件libmyhello.a和动态库文件libmyhello.so都已经生成，并都在当前目录中。然后，我们运行gcc命令来使用函数库myhello生成目标文件hello，并运行程序 hello。

$ gcc -o hello main.c -L. -lmyhello

$ ./hello

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

从程序hello运行的结果中很容易知道，当静态库和动态库同名时， gcc命令将优先使用动态库。