浅谈C/C++连接库

做者：施洪宝

一. 说明

• 一、本文后续代码的编译以及执行环境为Centos 7.6 x86_64, g++ 4.8.5
• 二、本文后续会用到linux下nm, ldd命令。nm用于查看文件中的符号, 例如变量, 函数名称。ldd用于查看动态连接库或者可执行文件的依赖库(动态连接库)。

二. 编译连接

• 一、程序员写出的代码为.c或者.cpp, 这些文件须要通过: 预处理(处理代码中的include, 宏等)、编译(生成汇编代码)、汇编(将汇编代码生成二进制文件)、连接才能生成可执行程序。本文将预处理、编译、汇编的过程都看作是编译, 简化读者理解。更多细节能够参考相关资料。
• 二、生成可执行文件后, 经过终端进行执行

• 三、g++参数说明,

  • -std=c++11: 使用c++11标准
  • -o: 指定输出文件名称

• 四、连接器ld参数:

  • -L: 指定连接时搜索的动态连接库路径
  • -l: 连接某个库, 例如连接libmath.so, 写为-lmath

2.1 编译

• 一、对于c或者c++项目而言, 咱们认为单个c或者cpp文件是一个编译单元, 经过编译器(gcc, g++, clang, clang++)能够生成编译后的二进制文件。例如: 编译file1.cpp, 能够生成file1.o。对于单个编译单元而言, 里面会有一些符号, 例如函数名称, 变量名称, 类名。这些符号能够分为三类:

  • 对外提供的, 也就是说其余的编译单元可使用的
  • 对外依赖的, 也就是说本单元须要外部的其余编译单元提供的符号
  • 本身内部使用的, 这种符号只有本编译单元自身须要使用, 外部不可见
• 二、经过nm, 咱们能够查看某个编译单元存在哪些符号

2.2 连接

• 一、C/C++项目中含有不少个c文件或者cpp文件, 这些文件通过编译生成了对应的二进制文件。须要经过连接器将这些文件连接, 进而生成可执行程序。
• 二、linux下连接器为ld, 利用该工具咱们能够将这些文件连接, 进而生成可执行程序。
• 三、在进行连接时, 每一个编译单元须要的符号, 都须要可以找到对应的定义。例如: 某个编译单元须要其余编译单元提供符号fun1, 这是一个函数, 若是连接器没能从其余编译单元找到这个符号, 就会报咱们常常看到的未定义错误。若果出现屡次, 则会报出重复定义的错误。

2.3 示例

• 一、math.h

#ifndef _MATH_H_
#define _MATH_H_

int add(int a, int b);

#endif

• 二、math.cpp

#include "math.h"

int add(int a, int b){
    return a + b;
}

• 三、main.cpp

#include <iostream>

#include "math.h"

using namespace std;

int main(int argc, char **argv){
    int a = 100, b = 200;
    int result = add(a, b);
    cout << result << endl;
}

• 四、生成可执行文件

  • 编译math.cpp: g++ -std=c++11 -c math.cpp, 生成math.o
  • 编译main.cpp: g++ -std=c++11 -c main.cpp, 生成main.o
  • 生成能够执行的文件: g++ -v math.o main.o -o main, 能够看到g++的编译连接过程

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/:/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.8.5/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.8.5/:/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'main' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/collect2 --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o main /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../.. main.o math.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crtn.o

• 其中最后一行调用collect2(对ld进行了包装)会执行真正的连接操做, 咱们直接调用这一句也能够生成main可执行文件
• 能够看出linux下的连接操做比较复杂, 不是简单的ld main.o math.o便可成功的。

三. 问题

经过上面的介绍, 咱们知道一个c/cpp文件经过编译连接, 最终生成可执行文件。不管任何语言, 程序员在写代码时, 都不可避免须要使用到库, 本文主要介绍C/C++中的库, 整体而言, 咱们将这些库分为静态连接库(一般以.a结尾)，动态连接库(一般以.so结尾)。首先咱们来看几个问题:

• 一、什么是静态连接库?什么是动态连接库?
• 二、静态连接库如何生成?动态连接库如何生成?
• 三、静态连接库是否能够依赖其余的静态连接库? 是否能够依赖其余动态连接库?
• 四、动态连接库是否能够依赖其余的静态连接库? 是否能够依赖其余的动态连接库?
• 五、连接静态库时?其依赖的库该如何连接?
• 六、连接动态库时?其依赖的库该如何连接?
• 七、使用第三方库时, 使用静态连接库仍是动态连接库?

四. Hello World

本节以hello world为例,

#include <iostream>
using namespace std;

int main(int argc, char **argv){
    cout << "hello world" << endl;
}

• 一、编译程序: g++ -std=c++11 -o main main.cpp
• 二、使用ldd查看main的依赖: ldd main

linux-vdso.so.1 =>  (0x00007ffcf53fa000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f7828b3b000)
libm.so.6 => /lib64/libm.so.6 (0x00007f7828839000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7828623000)
libc.so.6 => /lib64/libc.so.6 (0x00007f7828256000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7828e42000)

• 能够看出, 最简单的hello world程序也须要连接一些库
• 上述的几种连接库, 感兴趣的能够逐个研究

五. 动态连接库 vs 静态连接库

• 一、本节以2.3中的示例代码为例, 将math.h, math.cpp打包为静态连接库以及动态连接库, 在main.cpp中引用

5.1 静态连接库

• 一、编译: g++ -std=c++11 -fPIC -c math.cpp

  • fPIC用于生成位置无关的代码, 更多细节能够查找相关资料
• 二、生成静态连接库: ar -crv libmath.a math.o

• 三、使用这个静态连接库:

  • 使用静态库时, 咱们须要math.h文件, 这个文件中定义了这个库对外提供的功能
  • 除了math.h文件, 咱们须要在连接阶段连接libmath.a
• 四、示例: main.cpp中已经导入了math.h文件, 编译main.c并连接libmath.a, g++ -std=c++11 -o main main.cpp -L. -lmath
• 五、ldd main能够看出, main文件再也不依赖libmath.a文件

5.2 动态连接库

• 一、生成动态连接库: g++ -std=c++11 -shared -fPIC math.cpp -o libmath.so

• 二、使用动态连接库:

  • 须要使用math.h头文件, 该文件定义了库对外提供的功能
  • 连接阶段须要连接libmath.so
• 三、示例: g++ -std=c++11 -o main main.cpp -L. -lmath
• 四、执行main, 会发现没法执行

./main: error while loading shared libraries: libmath.so: cannot open shared object file: No such file or directory

• 五、咱们先用ldd 查看main的依赖库:

linux-vdso.so.1 =>  (0x00007ffd2adde000)
libmath.so => not found
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fd3b7ee6000)
libm.so.6 => /lib64/libm.so.6 (0x00007fd3b7be4000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd3b79ce000)
libc.so.6 => /lib64/libc.so.6 (0x00007fd3b7601000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd3b81ed000)

很奇怪, libmath.so没有找到, 咱们在第三步编译时明明将这个库加入进去了。这个是因为, 在连接阶段, 连接器能够在当前目录找到libmath.so。执行阶段, 搜索动态连接库时, 并无包含当前目录, 因此报错。咱们能够经过export LD_LIBRARY_PATH=/libpath将libmath.so所在路径放入动态连接库的搜索路径中。此时便可成功执行。

5.3 对比

• 一、静态连接库, 动态连接库都是二进制文件(ELF格式, 详细信息能够查找相关资料)

从静态连接库生成的过程来看, 其本质就是将多个编译单元(.o文件), 打包为一个新的文件。连接静态连接库时, 会将静态连接库的代码合并进程序中。

• 二、连接动态连接库时, 并不会将动态连接库的内容合并进代码中, 而是在程序执行时, 搜索动态连接库, 再进行连接。

六. 库之间的依赖

6.1 源代码

• 一、first.h

#ifndef __FIRST_H_
#define __FIRST_H_

#include <cstdio>

void first();

#endif

• 二、first.cpp

#include"first.h"

void first()
{
    printf("This is first!\n");
}

• 三、second.h

#ifndef __SECOND_H_
#define __SECOND_H_
 
#include <cstdio>
void second();

#endif

• 四、second.cpp

#include"first.h"
#include"second.h"

void second()
{
    printf("This is second!\n");
    first();
}

• 五、main.cpp

#include"second.h"
int main()
{
    second();
    return 0;
}

6.2 静态库依赖静态库

• 一、生成libfirst.a静态连接库

g++ -std=c++11 -fPIC -c first.cpp
ar -crv libfirst.a first.o

• 二、生成libsecond.a并连接libfirst.a

g++ -std=c++11 -c second.cpp -L. -lfirst
ar -crv libsecond.a second.o

• 三、main.cpp中使用libsecond.a

执行: g++ -std=c++11 main.cpp -L. -lsecond -o main
会出现如下错误:

./libsecond.a(second.o): In function second()': second.cpp:(.text+0xf): undefined reference tofirst()’
collect2: error: ld returned 1 exit status

• 四、解释说明

  • 经过nm, 咱们查看libsecond.a中的符号, 找出未定义的符号, 执行nm -u libsecond.a, 便可发现first并无定义(编译器编译后的符号并非first, 我这里是_Z5firstv)。咱们明明在生成libsecond.a时连接了libfirst.a?
  • 主要的缘由是: 生成静态连接库时, 只是将second.cpp生成的second.o打包, 并无真正的将libfirst.a中的内容连接进libsecond.a
  • 静态库不与其余静态库连接。咱们使用archiver工具(例如Linux上的ar)将多个静态连接库打包为一个静态连接库

• 五、解决方案

  • 将first.cpp, second.cpp打包为一个静态连接库: g++ -std=c++11 -fPIC -c first.cpp second.cpp, ar -crv libsecond.a first.o second.o。main中能够直接连接libsecond.a便可

同时连接libsecond.a, libfirst.a

6.3 动态库依赖静态库

• 一、生成libfirst.a静态连接库, 这一步与5.2节相同
• 二、生成libsecond.so静态连接libfirst.a

g++ -std=c++11 second.cpp -fPIC -shared -o libsecond.so -L. -lfirst

• nm -u libseond.so, 咱们能够看出, 并无出现first, 也就是说, libfirst.a已经被连接进libsecond.so中了

• 三、编译main.cpp

g++ -std=c++11 main.cpp -L. -lsecond -o main

6.4 静态库依赖动态库

• 一、生成libfirst.so

g++ -std=c++11 first.cpp -shared -fPIC -o libfirst.so

• 二、生成libsecond.a连接libfirst.so

g++ -std=c++11 -c second.cpp -fPIC -L. -lfirst
ar crv libsecond.a second.o

nm -u libsecond.a, 能够看到_Z5firstv, 说明并无将libfirst.so中包含进libsecond.a

• 三、编译main.cpp

g++ -std=c++11 main.cpp -L. -lsecond -lfirst -o main

若是没有连接first, 会发现连接错误, 找不到first函数的定义

6.5 动态库依赖动态库

• 一、生成libfirst.so

g++ -std=c++11 first.cpp -shared -fPIC -o libfirst.so

• 二、生成libsecond.so连接libfirst.so

g++ -std=c++11 second.cpp -shared -fPIC -o libsecond.so -L. -lfirst

nm -u libsecond.so, 能够看到_Z5firstv, 这个就是first函数
ldd libsecond.so, 也能够看到libfirst.so
能够看出, 使用libsecond.so时, 仍然须要libfirst.so

• 三、编译main.cpp

g++ -std=c++11 main.cpp -L. -lsecond -o main

能够看出, 可以成功编译。
以前讲过libsecond.so须要依赖libfirst.so, 此处为什么咱们只连接libsecond.so也能成功呢?这里是由于连接器会自动搜索动态连接库的依赖库

七. 总结

• 一、c或者cpp文件通过编译、连接生成可执行文件
• 二、单个c文件或者cpp文件是一个编译单元。每一个编译单元存在3种符号: 本身使用的, 依赖于外部的以及对外提供的。
• 三、连接器是将多个编译单元的符号相互连接以造成可执行文件。
• 四、库能够分为静态连接库(.a)以及动态连接库(.so)。
• 五、使用库时, 除了库文件, 还须要对应的头文件。
• 六、单个c文件或者cpp文件, 可能依赖其余的库文件, 可是在编译时, 只须要有声明, 并不须要有具体的定义。
• 七、静态库没有连接操做, 静态库只是将多个.o文件打包, 并无其余操做。静态库可能依赖其余的静态库或者其余的动态库, 用户在使用静态库时, 须要手动连接这些依赖。
• 八、动态库有连接操做, 建立动态库时能够连接其余的库, 也能够不连接, 若是连接静态库, 则会将静态库的内容所有放入动态库, 若是连接动态库, 只是放入符号, 在程序初始化时, 将依赖的这些动态库也加载。若是这个动态库依赖了其余库, 可是没有连接, 也能够生成动态库, 但用户在使用这个动态连接库时, 须要手动连接这些依赖, 因为使用者很难知道这些依赖, 因此一般不使用这种方式。
• 九、整体而言, 动态库在程序执行阶段才会装进程序, 静态库则在连接阶段直接放进程序。动态库能够由多个程序共享, 节省内存，易于升级。静态库外部依赖少, 更易于部署。

八. 扩展

• 一、动态库升级问题?假设如今有2个程序: p1, p2, 一个动态连接库libmath.so.1。若是如今math库提供了新版本libmath.so.2, 程序p1须要使用libmath.so.2的新功能, p2则不想使用, 此时该如何升级math库?

  • 若是math不兼容前一版, 则系统中须要同时存在两个版本的math库, p1, p2分别连接不一样的版本
  • 若是math兼容前一版, 系统中是否能够只保留新版的math库呢?此时p1, p2又是否须要从新编译呢?这个问题留给读者自行思考。

• 二、某个动态连接库lib1动态连接了库libbase, 如今应用程序中使用了lib1以及libbase, 编译应用程序时, 是否须要连接libbase?

  • 应用程序不只须要连接lib1, 也须要连接libbase
  • 连接lib1只能保证应用程序依赖lib1的部分可以正确解析
  • 虽然lib1动态连接了libbase, 可是动态连接真正进行符号解析是在程序执行阶段, 编译阶段没法获取libbase的相关信息, 应用程序中若是也使用了libbase中的函数, 则必须连接libbase, 不然会出现符号未定义
  • 若是lib1静态连接了libbase, 也就是说包含了libbase中的函数, 则应用程序不须要在连接libbase

• 三、菱形依赖问题, A依赖于B以及C, B、C都依赖于D, 可是是不一样版本, 例如B依赖于D1, C依赖于D2, 这种状况下如何连接?

  • D2兼容于D1(ABI层面兼容), 程序直接连接D2
  • D2不兼容于D1, 查看B是否能够依赖D2从新编译

连接器的参数, 直接连接两个版本。ld的参数–default-symver或者–version-script

• 四、讨论

  • 动态连接会有大量的依赖问题(windows dll hell)
  • 因为采用模块化, 又容许升级单个模块, 菱形依赖问题对于不少语言都是存在的
  • rust, go等语言都开始采用源码编译的方式, 解决依赖问题

九. 参考

http://blog.chinaunix.net/uid...
https://www.cnblogs.com/fnlin...
https://blog.csdn.net/coolwat...
https://blog.habets.se/2012/0...