Linux下动态链接库的2种链接方式
方式一
通过 dlopen, dlsym, dlerror, dlclose 在代码中直接打开与使用动态链接库
- dlopen 用于打开动态链接库，返回句柄
- dlsym 使用dlopen返回的句柄与函数名来获得函数位置，返回函数指针
- dlclose 关闭动态链接库
- dlerror 当动态链接库函数操作失败时，返回出错信息；NULL表示成功
看以下示例程序
// fibo.cpp
#include <iostream>
#include <vector>
using namespace std;
// Unmangling the function name for dlsym convenience, as this is C++ file
extern "C" {
unsigned long fibo(int n);
}
unsigned long fibo(int n)
{
unsigned long vec[94] = {0, 1, 1};
long result = 0;
if (n <= 0 || n > 93) { // know why choose 93? Haha
result = 0;
}
else { // 1 <= n <= 93
for (int i=3; i<=n; i++) {
vec[i] = vec[i-1] + vec[i-2];
}
result = vec[n];
}
return result;
}该程序需使用如下命令编译成动态链接库
g++ -fPIC -shared fibo.cpp -o libfibo.so在程序中，之所以使用 extern “C” 来声明 fibo 函数，是因为这个源代码文件是一个C++文件，默认编译出来的so文件中的fibo函数的名字是会被 mangling 的。这就会引起使用者在调用 dlsym 函数获取 fibo 函数地址的时候，需要填写一个mangling的名称，而不是直接写 “fibo”, 从而造成不便。为了使用者的方便，这里用 extern “C” 来声明 fibo，以去除名称的mangling.
另外，我们可以使用以下2个命令中的任何一个来验证fibo函数的命令在库中已经被unmangling了。
objdump -t libfibo.so | grep fibo
nm libfibo.so | grep fibo以下是调用者程序：
// use_libfibo_way1.cpp
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
#include <iostream>
using namespace std;
#define LIB_FIBO_PATH "./libfibo.so"
typedef unsigned long (*FUNC_PTR)(int);
int main()
{
char * error;
void * handler = dlopen(LIB_FIBO_PATH, RTLD_LAZY);
if (!handler) {
fprintf(stderr, "%s\n", dlerror());
exit(EXIT_FAILURE);
}
FUNC_PTR fibo = (FUNC_PTR)(dlsym(handler, "fibo"));
if ((error = dlerror()) != NULL) {
fprintf(stderr, "%s\n", error);
exit(EXIT_FAILURE);
}
cout << "fibo[3] = " << fibo(3) << endl;
cout << "fibo[5] = " << fibo(5) << endl;
cout << "fibo[93] = " << fibo(93) << endl;
dlclose(handler);
return 0;
}该程序需使用如下命令编译：
g++ -rdynamic use_libfibo_way1.cpp -ldl -o a1.out运行时，直接运行 a1.out 即可。
可以看出，这种调用动态链接的方式的缺点是：
- 需要在程序中或配置文件里注明库文件的位置
- 需使用额外的库函数 dlopen, dlsym, dlerror, dlclose 来辅助工作
优点是：
可以不用include头文件
方式二
编译时使用链接选项指定动态链接库
调用者程序如下：
// use_libfibo_way2.cpp
#include <iostream>
using namespace std;
extern "C" {
unsigned long fibo(int n);
}
int main()
{
cout << "fibo[3] = " << fibo(3) << endl;
cout << "fibo[5] = " << fibo(5) << endl;
cout << "fibo[93] = " << fibo(93) << endl;
return 0;
}该程序使用如下命令进行编译：
g++ use_libfibo_way2.cpp -L. -lfibo -o a2.out而运行 a2.out 时，假如 libfibo.so 并不在系统搜索路径中，即不在环境变量 LD_LIBRARY_PATH 中，则需加入，然后运行：
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
./a2.out如果不想运行依赖于环境变量，可以在编译的时候使用这个命令：
g++ way2.cpp -lfibo -o a2.out -L. -Wl,-rpath=.这里的 “-rpath=.” 就表示把”当前路径作为搜索路径“传递给了链接器。于是直接运行 ./a2.out 而不用改变环境变量 LD_LIBRARY_PATH 了。
这种方式的优点是：
程序简洁，不用依赖于其他库，即不用依赖 dlopen, dlsym, dlerror, dlclose 所在的 libdl.so 库
缺点是：
一般都需要include头文件（虽然本例中没有include头文件，那只是因为程序简单）
其他
方式二是常用的方式，但是方式一也需要知道。为何呢?
除了因为方式一可能有其特定的使用场合之外，还有一个原因：
如果使用 ldd 命令来查看一个二进制文件都链接了哪些动态链接库，你会发现方式二的 a2.out 的输出中有 libfibo.so , 而方式一的 a1.out 的输出中没有 libfibo.so!
这是意料之中的，因为a1.out在其编译选项中本就没有用到 libfibo.so, 不过它用到了 libdl.so , 因此可以看到这个库。
这就意味着 ldd 命令无法看出方式一的二进制文件究竟链接了哪些动态链接库，唯有看源码才能看到。
ldd的输出如下：
$ldd a1.out
linux-vdso.so.1 (0x00007ffc4a3fd000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc1f87b8000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fc1f842f000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc1f8075000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc1f8bbf000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc1f7d2a000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc1f7b13000)
$ldd a2.out
linux-vdso.so.1 (0x00007ffddf591000)
libfibo.so => not found >>> 因为没有运行 export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH 否则可以找到
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f3266225000)
libc.so.6 => /lib64/libc.so.6 (0x00007f3265e6b000)
libm.so.6 => /lib64/libm.so.6 (0x00007f3265b20000)
/lib64/ld-linux-x86-64.so.2 (0x00007f32667b1000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3265909000)(完)
