1. 静态库和动态库的基本概念 静态库,是在可执行程序连接时就已经加入到执行码中,在物理上成为执行程序的一部分;使用静态库编译的程序运行时无需该库文件支持,哪里都可以用, 但是生成的可执行文件较大。动态库,是在可执行程序启动时加载到执行程序中,可以被多个可执行程序共享使用。使用动态库编译生成的程序相对较小,但运行时 需要库文件支持,如果机器里没有这些库文件就不能运行。 2. 如何使用动态库 如何程序在连接时使用了共享库,就必须在运行的时候能够找到共享库的位置。linux的可执行程序在执行的时候默认是先搜索/lib和/usr /lib这两个目录,然后按照/etc/ld.so.conf里面的配置搜索绝对路径。同时,Linux也提供了环境变量LD_LIBRARY_PATH 供用户选择使用,用户可以通过设定它来查找除默认路径之外的其他路径,如查找/work/lib路径,你可以在/etc/rc.d/rc.local或其 他系统启动后即可执行到的脚本添加如下语句:LD_LIBRARY_PATH =/work/lib:$(LD_LIBRARY_PATH)。并且LD_LIBRARY_PATH路径优先于系统默认路径之前查找(详细参考《使用 LD_LIBRARY_PATH》)。 不过LD_LIBRARY_PATH的设定作用是全局的,过多的使用可能会影响到其他应用程序的运行,所以多用在调 试。(LD_LIBRARY_PATH的缺陷和使用准则,可以参考《Why LD_LIBRARY_PATH is bad》 )。通常情况下推荐还是使用gcc的-R或-rpath选项来在编译时就指定库的查找路径,并且该库的路径信息保存在可执行文件中,运行时它会直接到该路 径查找库,避免了使用LD_LIBRARY_PATH环境变量查找。 3.库的链接时路径和运行时路径 现代连接器在处理动态库时将链接时路径(Link-time path)和运行时路径(Run-time path)分开,用户可以通过-L指定连接时库的路径,通过-R(或-rpath)指定程序运行时库的路径,大大提高了库应用的灵活性。比如我们做嵌入式 移植时#arm-linux-gcc $(CFLAGS) –o target –L/work/lib/zlib/ -llibz-1.2.3 (work/lib/zlib下是交叉编译好的zlib库),将target编译好后我们只要把zlib库拷贝到开发板的系统默认路径下即可。或者通过 -rpath(或-R )、LD_LIBRARY_PATH指定查找路径。 小问题: 1.编译时的-L选项是否影响LD_LIBRARY_PATH的值? 举一个实例: 当前文件夹结构如下: test.c tools/ tool下有tool.c tool.h my_err.h 以及由此生成的libtool.so tool下编译生成库文件 gcc -Wall -g -shared -o tool.so tool.c 在当前文件夹引用: gcc -Wall -g -o test test.c -Ltools -ltool 编译不报错,但是运行加载的时候就出现cannot open shared object file。 如果将该库文件拷贝到/usr/lib下就没有错误,正常运行。 说明编译时的-L选项并不影响环境变量LD_LIBRARY_PATH,-L只是指定了程序编译连接时库的路径,并不影响程序执行时库的路径,系统还是会到默认路径下查找该程序所需要的库。 共享库(Shared Libary)/动态链接库http://feizf.blogbus.com/logs/6586196.html 有两种方法使用lib库 一个简单的汇编使用libc链接库的例子如下: 编译连接 dynamically-linked 在Windows平台叫dll动态链接库,在Linux平台下称为共享库,一般存放在/lib、
-------------------------------------------------------------- 现在要把所有这些.o用到的文件做成一个共享库librecord.so (这也符合共享库的含义,可以被其他程序使用), 如下: 接着来使用这个共享库 其中:
这是因为默认情况下linker只在/lib、/usr/lib和/etc/ld.so.conf中列出的目录中寻找共享库. 所以要想正常运行程序,要么把共享库移到相关目录下,要么修改LD_LIBRARY_PATH把当前目录.加入
|