调用动态库的时候有几个问题会经常碰到,有时,明明已经将库的头文件所在目录 通过 “-I” include进来了,库所在文件通过“-L”参数引导,并指定了“-l”的库名,但通过ldd命令察看时,就是死活找不到你指定链接的so文件,这时你要作的就是通过修改LD_LIBRARY_PATH或者/etc/ld.so.conf文件来指定动态库的目录。通常这样做就可以解决库无法链接的问题了。
一、 静态库:
1.概念:
静态库就是一些目标文件的集合,以.a结尾。静态库在程序链接的时候使用,链接器会将程序中使用
到函数的代码从库文件中拷贝到应用程序中。一旦链接完成,在执行程序的时候就不需要静态库了。
由于每个使用静态库的应用程序都需要拷贝所用函数的代码,所以静态链接的文件会比较大。
2.创建与应用:
首先创建库文件libhello.c
#include
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
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
#include
#include
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 版本的众多与各自独立性,在工程制作与使用中必须熟练掌握如下两点才能有效地工作和理想地运行。
三种标准库链接方式选项及对比
为了演示三种不同的标准库链接方式对最终应用程序产生的区别,这里用了一个经典的示例应用程序 HelloWorld 做演示,见 清单 1 HelloWorld。整个工程可以在文章末尾下载。
#include |
三种标准库链接方式的选项及区别见 表 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=
为了区分三种不同的标准库链接方式对最终生成的可执行文件的影响,本文从两个不同的维度进行分析比较:
维度一:最终生成的可执行文件对标准库的依赖方式(使用 ldd 命令进行分析)
ldd 简介:该命令用于打印出某个应用程序或者动态库所依赖的动态库
涉及语法:ldd [OPTION]... FILE...
其他详细说明请参阅 man 说明。
三种标准库链接方式最终产生的应用程序的可执行文件对于标准库的依赖方式具体差异见 图 1、图 2、图 3所示:
通过上述三图,可以清楚的看到,当用 全静态标准库的链接方式时,所生成的可执行文件最终不依赖任何的动态标准库,
而 全动态标准库的链接方式会导致最终应用程序可执行文件依赖于所有用到的标准动态库。
区别于上述两种方式的 半静态链接方式则有针对性的将 libgcc 和 libstdc++ 两个标准库非动态链接。
(对比 图 2与 图 3,可见在 图 3中这两个标准库的动态依赖不见了)
从实际应用当中发现,最理想的标准库链接方式就是半静态链接,通常会选择将 libgcc 与 libstdc++ 这两个标准库静态链接,
从而避免应用程序在不同 Linux 版本间标准库依赖不兼容的问题发生。
维度二 : 最终生成的可执行文件大小(使用 size 命令进行分析)
size 简介:该命令用于显示出可执行文件的大小
涉及语法:size objfile...
其他详细说明请参阅 man 说明。
三种标准库链接方式最终产生的应用程序的可执行文件的大小具体差异见 图 4、图 5、图 6所示:
通过上述三图可以看出,最终可执行文件的大小随最终所依赖的标准动态库的数量增加而减小。
从实际应用当中发现,最理想的是 半静态链接方式,因为该方式能够在避免应用程序于
不同 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 [
示例情景:
假设现有如 图 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 下静态库的制作。
这样的 demo.a 当被链接入某个工程时,所有在 TXmlParser.o 和 xmlparser.o 定义的符号都不会被发现,从而会导致链接错误,
提示无法找到对应的符号。显然,通过图 8 方式创建 Linux 静态库是不正确的。
正确的方式有两种:
显然,方式 1 是比较麻烦的,因为涉及到太多的文件处理,可能还要通过不断创建临时目录用于保存中间文件。
推荐使用如 清单 2 createlib.sh所示的 ar 脚本方式进行创建:
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所示的代码:
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 才是我们想要的结果。
回页首
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)。
我们试着把这个例子变成代码,首先定义
1 |
#ifndef MONEY_H |
2 |
#define MONEY |
3 |
void showmethemoney( int money); |
4 |
#endif |
1 |
#include |
2 |
void showmethemoney( int money){ |
3 |
printf ( "$%d\n" ,money); |
4 |
} |
接下来,分别把money搞成现金和银行卡。但无论怎样,link之前的compile,即编译成.o文件是必需的。
1 |
[root@backup kongch] # ls |
2 |
money.c money.h |
3 |
[root@backup kongch] # gcc -c money.c |
4 |
[root@backup kongch] # ls |
5 |
money.c money.h money.o |
静态库文件名的命名规范是以lib为前缀,紧接着跟静态库名,扩展名为.a。
我们将创建的静态库名为cash,则静态库文件名就是libcash.a。在创建和使用静态库时,需要注意这点。创建静态库用ar命令:
1 |
[root@backup kongch] # ls |
2 |
money.c money.h money.o |
3 |
[root@backup kongch] # ar crv libcash.a money.o |
4 |
a - money.o |
5 |
[root@backup kongch] # ls |
6 |
libcash.a money.c money.h money.o |
动态库文件名命名规范和静态库文件名命名规范类似,也是在动态库名增加前缀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 `a local symbol' can not be used when making a shared object; recompile with -fPIC |
3 |
money.o: could not read symbols: Bad value |
4 |
collect2: ld returned 1 exit status |
我在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 |
4 |
total 32 |
5 |
drwx------ 2 root root 4096 Nov 1 15:04 . |
6 |
drwx------ 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.
1 |
#include "money.h" |
2 |
3 |
int main(){ |
4 |
showmethemoney(100); |
5 |
return 0; |
6 |
} |
告诉gcc静态链接库在哪里就可以了:
1 |
[root@backup kongch] # gcc -o cash main.c -L. -lcash |
2 |
$100 |
3 |
[root@backup kongch] # ls -la |
4 |
total 44 |
5 |
drwx------ 2 root root 4096 Nov 1 15:11 . |
6 |
drwx------ 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 |
3 |
total 52 |
4 |
drwx------ 2 root root 4096 Nov 1 15:15 . |
5 |
drwx------ 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 while loading shared libraries: libbank.so: cannot open shared object file : No such file or directory |
失败了。这就需要我们搞清楚动态链接、执行时搜索路径顺序:
我们通过2、3两种方式来让我们的bank正常:
在执行前手动指定so所在路径,但就像你知道的,这样的指定是seesion级别的,每次执行都要这么来:
1 |
[root@backup kongch] # LD_LIBRARY_PATH=. ./bank |
2 |
$100 |
手动指定/etc/ld.so.conf里包含的路径,比如我的测试server上
1 |
[root@backup kongch] # cat /etc/ld.so.conf |
2 |
include 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