当前位置：首页 > news >正文

动静态库原理与ELF文件详解

news 2026/3/27 2:51:12

1. 什么是库

所有的库，本质都是源文件对应的 .o 文件
动静态库中不要包含 main 函数
静态库: .a[linux]、.lib[windows]
动态库:.so[linux]、.dll[windows]

2. 静态库

静态库（.a）：程序在链接的时候把代码链接到可执行文件中，程序运行的时候不再需要静态库
编译默认使用动态链接库，gcc的 -static 强制设置链接静态库

2.1 静态库生成

静态库命名必须遵守 libxxx.a

ar -rc libmyc.a *.o # 把所有 .o 文件打包成 xxx.a

2.2 静态库使用

# 场景1：头文件和库文件安装到系统路径下 gcc main.c -lmystdio # 场景2：头文件和库文件和我们的源文件在同一个路径下 gcc main.c -L . -lmymath # 场景3：头文件和库文件有自己的独立路径 gcc main.c -I 头文件路径 -L 库文件路径 -lmymath

选项（可以不留空格）
- -L：指定库路径
- -I（大写）：指定头文件搜索路径
- -l（小写）：指定库名
库文件名称和引入库的文件
- 去掉前缀 lib 和后缀 .a / .so ，如 libc.a -> c

3. 动态库

动态库（.so）：程序在运行的时候才去链接动态库的代码，多个程序共享使用库的代码
动态库可以在多个程序间共享，所以动态链接使得可执行文件更小，节省磁盘空间

3.1 动态库生成

# 1. 生成位置无关的目标文件 .o gcc -c -fPIC test.c add.c ... # 2. 生成动态库 gcc -shared -o libmy.so *.o

shared：表示生成共享库模式
fPIC：产生位置无关码
库文件名称和引入库的文件
- 去掉前缀 lib 和后缀 .a / .so ，如 libc.so -> c

3.2 动态库的使用

gcc main.c -I 头文件路径 -L 库文件路径 -lmymath

选项（可以不留空格）
- L：指定库路径
- I（大写）：指定头文件搜索路径
- l（小写）：指定库名

3.3 库运行搜索路径

问题：编译时用 -L 能找到库生成可执行文件，但是系统不知道导致运行时找不到对应库文件
解决方法：
- 拷贝 .so 文件到系统共享库路径下，一般指 /usr/lib、/usr/local/lib、/lib64 或者开篇指明的库路径
- 向系统库路径下建立同名软连接
- 更改环境变量（临时，常用）：LD_LIBRARY_PATH
- ldconfig方案：配置 /etc/ld.so.conf.d/,使用ldconfig更新

3.4 总结

结论1：gcc/g++默认使用动态库，想用静态链接只能提供静态库并加 -static
结论2：在linux系统下，默认情况安装的大部分库，默认都优先安装的是动态库
结论3：库：应用程序 = 1：n
结论4：vs不仅仅形成可执行程序，也能形成动静态库

4. 目标文件

.o/.obj：可重定位目标文件
目标文件（.o文件）是一个二进制文件，文件格式是 ELF，是对二进制代码的一种封装
动静态库、可执行程序、可重定位目标文件都是 ELF 格式的

5. ELF文件

ELF文件：
- 可重定位目标文件：即 xxx.o 文件
- 可执行文件：即可执行程序
- 共享目标文件：即 xxx.so 文件(静态库是 xxx.o 的打包压缩包，不属于)
- 内核转储：存放当前程序的执行上下文，用于dump信号触发
ELF文件组成
- ELF头：描述文件的主要特性
- 程序头表：列举所有有效的段和属性
- 节头表：包含对节的描述
- 节：ELF文件的组成单位，包含特定类型的数据
  - 代码节(.txt)：保存机器指令，是程序的主要执行部分
  - 数据节(.data)：保存已初始化的全局变量和局部静态变量

6.ELF从形成到加载轮廓

6.1 ELF形成可执行

step1（前置步骤）：将多份 C/C++ 源代码，翻译成目标 .o 文件 + 动静态库（ELF）
step2：将多份 .o 文件 section 进行合并

6.2 ELF可执行文件加载

一个 ELF 会有多种不同的 Section，在加载到内存的时候，也会进行 Section 合并，形成 segment
合并原则：相同属性，比如：可读，可写，可执行，需要加载时申请空间等
为什么要将 section 合并成为 segment？
- 为了减少页面碎片，提高内存效率
链接视图 – 对应节头表 Section header table
- 静态链接的时候一般关注的是链接视图
执行视图 – 对应程序头表 Program header table
- 如何加载可执行文件
- 告诉操作系统哪些模块可以被加载进内存
ELF HEADER
- 主要目的是定位文件的其他部分

7. 链接与加载

7.1 静态链接

研究静态链接，本质就是研究 .o 是如何加载的
在 .o 文件中，不知道调用函数的地址，所以在汇编时，编译器只是将函数的跳转地址先暂时设为0
- 链接的时候这个地址会修正
- 多个 .o 合并之后，在最终的可执行程序中，就知道函数对应的地址了
静态链接就是把库中的 .o 进行合并，并修正他们的地址
链接过程中会涉及到对 .o 中外部符号进行地址重定位

7.2 ELF加载与进程地址空间

7.2.1 虚拟地址/逻辑地址

一个ELF程序，在没有被加载到内存的时候就有地址
- ELF的逻辑地址（起始地址+偏移量）认为是起始地址0
进程 mm_struct、vm_area_struct 在刚创建的时候数据从哪里来？
- 从 ELF 各个 segment 来，每个 segment 都有自己的起始地址和自己的长度，用来初始化内核结构中的 [start,end] 等范围数据秒另外再用详细地址填充页表
虚拟地址机制，不光要OS支持，编译器也要支持

7.2.2 理解进程地址空间

磁盘里的 ELF 存的是虚拟地址；加载到内存后，内核建立虚拟地址到物理地址的映射；CPU 永远用虚拟地址，由 MMU 转成物理地址去执行；mm_struct 和 vm_area_struct 管理这个映射关系，真正的映射写进页表

7.3 动态链接与动态库加载

库函数调用
- 1.被进程看到：动态库映射到进程的地址空间
- 2.被进程调用：在进程的地址空间中进行跳转

7.3.1 进程如何看到动态库

进程通过虚拟地址看到动态库

7.3.2 进程间如何共享库的

动态库中的代码不会重复出现了

7.3.3 动态链接

7.3.3.1 概要

静态链接会将编译产生的所有目标文件，连同用到的各种库，合并形成一个独立的可执行文件
- 静态链接的最大问题在于生成的文件体积大，并且相当耗费内存资源
动态链接将连接的整个过程推迟到了程序加载的时候
- 将需要共享的代码提取出来，保存成一个独立的动态链接库，等到程序运行的时候再将它们加载到内存，不但可以节省空间，还因为同一模块在内存中只需要保留一份副本，可以被不同的进程共享