引用自http://blog.csdn.net/lwhsyit/article/details/2828306
类似Windows系统中的动态链接库，Linux中也有相应的共享库用以支持代码的复用。Windows中为*.dll，而Linux中为*.so，我来详细的告诉你如何在linux下编写动态库,以及如何使用它.
在linux下编写动态链接库的步骤:
1. 编写库的头文件和源文件.
2. 把所有涉及到的源文件用如下方式编译为目标文件:
g++/gcc -g -c -fPIC -o library1.o library1.cpp
g++/gcc -g -c -fPIC -o library2.o library2.cpp
......
......
（注释：-fPIC指通过这个选项来生成与位置无关的代码，可以在任何地址被连接和装载，-c指只编译而不连接原程序）
3. 把所有的目标文件链接为动态库:
g++/gcc -g -shared -Wl,-soname,lib***.so -o lib***.so.1.0.0 library1.o library2.o .... -lc
（注释：-lc选项，表示使用c语言库，一般都要用到）
4. 建立一个库名链接
ln -s lib***.so.1.0.0 lib***.so
现在你就可以引用库了.下面我分别给出简单例子告诉你如何动态和静态使用动态库:
假如你的应用程序源代码叫testlib.cpp
采用/如下方式编译:
g++ -g -o testlib testlib.cpp -ldl
（注释：-ldl选项，表示生成的对象模块需要使用共享库）
这个例子告诉你如何动态的调用.so库
testlib.cpp
#include <dlfcn.h>
#include <iostream.h>
#include ...
int main()
{
void *handle=NULL;
//define a pointer which will point to the function in the lib you want to use.
YourFuntionType (*pFunc)(YourFunctionPerameterList........);
//open the lib you want to use.
handle=dlopen("/http://www.cnblogs.com/../yourlib.so",RTLD_LAZY);
if(handle==NULL)
{
cout<<"failed loading library!"<<endl;
return -1;
}
dlerror();
//try to load the function in lib
pFunc=(YourFuntionType(*)(YourFunctionPerameterList))dlsym(handle,"YourFuntionName");
if(dlerror()!=NULL)
{
cout<<"Loading function in lib error!"<<endl;
return -1;
}
//now you can use the funtion like this
(*pFunc)(YourFuntionPerameterList);
return 0;
}
（注释：dlopen()
第一个参数：指定共享库的名称，将会在下面位置查找指定的共享库。
－环境变量LD_LIBRARY_PATH列出的用分号间隔的所有目录。
－文件/etc/ld.so.cache中找到的库的列表，用ldconfig维护。
－目录usr/lib。
－目录/lib。
－当前目录。（这里就是这种情况）
第二个参数：指定如何打开共享库。
－RTLD_NOW：将共享库中的所有函数加载到内存
－RTLD_LAZY： 会推后共享库中的函数的加载操作，直到调用dlsym()时方加载某函数
dlsym()
调用dlsym时，利用dlopen()返回的共享库的phandle以及函数名称作为参数，返回要加载函数的入口地址。
dlerror()
该函数用于检查调用共享库的相关函数出现的错误。
）
特别需要注意的几点问题:
1. 当你想用c++写动态库的时候,记住千万别忘了在头文件里面加上如下内容,否则生成的库在动态调用的时候会出问题!!!!!!!
#ifdef __cplusplus
extern "C" {
#endif
....
....
#ifdef __cplusplus
}
#endif
2. 当你的库中包括与omniORB3相关的东西的时候,一定要在makefile中加上 -D__x86__ -D__OSVERSION=4
/这个例子告诉你如何静态调用.so库
首先你得确保你的应用程序能够找到你的.so库,这可以有几种方法来实现.
方法一:
1.你可以把YourLib.so.1.0.0 和YourLib.so放到/usr/lib中,然后执行命令:ldconfig,这样你就可以在你的应用程序中直接调用你库中的函数了,当然你 得把库的头文件包含到你的应用程序中
2.编译你的应用程序
g++/gcc -g -o yourapp yourapp.cpp –lYourLib
方法二:
1.你也可以采用在系统中设置环境变量的办法来实现. 在root目录下:
vi .bash_profile
然后添加LD_LIBRARY=/../YourDirIncludingYourLib
然后注消一次,环境变量就生效了,这样你就可以在你的应用程序中直接调用库中的函数了,同样你得有头文件.
2.编译你的应用程序
g++/gcc -g -o yourapp yourapp.cpp –lYourLib
方法三:
你可以直接采用在编译链接的时候告诉系统你的库在什么地方
g++/gcc -g -o yourapp yourapp.cpp -L/YourDirIncludingYourLib –lYourLib
如： g++/gcc -g -o yourapp yourapp.cpp -L. –lYourLib
-L. :当前目录
/
假如你的库中有个函数:int eat(.....)
那么采用如下方式调用它
yourapp.cpp
#include "YourLib.h"
int main()
{
eat();
return 0;
}
是不是很easy?对了在静态调用的时候好像不存在上面的"注意1"的问题,不过鉴于保险起见,最好还是按照标准的方式写c++头文件吧,这绝对是个好习惯.
面通过一个简单的例子开始介绍Linux标准对象。
我们的标准对象文件含有一个函数，不需要声明export导出符号，只需要编译器设置即可。如下:
设建立一个tools.h文件以及tools.c文件
/*
** tools.h
*/
#include "stdio.h"
#include "stdlib.h"
void draw();
void write();
void sign();
void show();
/*
**tools.c
*/
#include "tools.h"
void draw()
{
printf("draw some graphics./n");
}
void write()
{
printf("write some characters./n");
}
void sign()
{
printf("sign your name./n");
}
void show()
{
printf("A picture by xufeng./n");
draw();
write();
printf("A picture is finished./n");
}
按照如下编译：
$ gcc -fPIC -shared -o libmytools.so tools.c
执行生成一个libmytools.so文件，按照Linux标准对象的命名惯例，应该在库名称之前加上"lib"前缀，尽管不是必须的。编译开关-fPIC代表函数符号可以重定向，-shared代表编译结果是一个标准对象。
不同于Win32DLL，Linux标准对象中的所有函数都是直接导出的，都可以被调用程序所访问。下面我们编写调用程序：
/*
** test.c
*/
#include "tools.h"
main()
{
show();
printf("success!/n");
}
按照如下gcc编译：
$ gcc -o test test.c ./libmytools.so
编译生成test可执行文件。如上编译条件的最后一条需要是所调用的标准对象文件名，注意必 须含有路径。如果只是使用libmyso.so，则必须确保这个文件在可访问的PATH下面。本例所使用的文件名"./libmytools.so"是当 前路径下的，使用了相对路径。
引用自：http://blog.csdn.net/lwhsyit/article/details/2830783
库文件在连接（静态库和共享 库）和运行（仅限于使用共享库的程序）时被使用，其搜索路径是在系统中进行设置的。一般 Linux 系统把 /lib 和 /usr/lib 两个目录作为默认的库搜索路径，所以使用这两个目录中的库时不需要进行设置搜索路径即可直接使用。对于处于默认库搜索路径之外的库，需要将库的位置添加到 库的搜索路径之中。设置库文件的搜索路径有下列两种方式，可任选其一使用：
在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。
在 /etc/ld.so.conf 文件中添加库的搜索路径。
将自己可能存放库文件的路径都加入到/etc/ld.so.conf中是明智的选择
添加方法也极其简单，将库文件的绝对路径直接写进去就OK了，一行一个。例如：
/usr/X11R6/lib
/usr/local/lib
/opt/lib
需要注意的是：第二种搜索路径的设置方式对于程序连接时的库（包括共享库和静态库）的定位已经足够了，但是对于使用了共享库的程序的执行还是不够的。这是 因为为了加快程序执行时对共享库的定位速度，避免使用搜索路径查找共享库的低效率，所以是直接读取库列表文件 /etc/ld.so.cache 从中进行搜索的。/etc/ld.so.cache 是一个非文本的数据文件，不能直接编辑，它是根据 /etc/ld.so.conf 中设置的搜索路径由 /sbin/ldconfig 命令将这些搜索路径下的共享库文件集中在一起而生成的（ldconfig 命令要以 root 权限执行）。
因此，为了保证程序执行时对库的定位，在 /etc/ld.so.conf 中进行了库搜索路径的设置之后，还必须要运行 /sbin/ldconfig 命令更新 /etc/ld.so.cache 文件之后才可以。ldconfig ,简单的说，它的作用就是将/etc/ld.so.conf列出的路径下的库文件缓存到/etc/ld.so.cache 以供使用。因此当安装完一些库文件，(例如刚安装好glib)，或者修改ld.so.conf增加新的库路径后，需要运行一下 /sbin/ldconfig使所有的库文件都被缓存到ld.so.cache中，如果没做，即使库文件明明就在/usr/lib下的，也是不会被使用 的，结果编译过程中抱错，缺少xxx库，去查看发现明明就在那放着，搞的想大骂computer蠢猪一个。
在程序连接时，对于库文件（静态库和共享库）的搜索路径，除了上面的设置方式之外，还可以通过 -L 参数显式指定。因为用 -L 设置的路径将被优先搜索，所以在连接的时候通常都会以这种方式直接指定要连接的库的路径。
前面已经说明过了，库搜索路径的设置有两种方式：
在环境变量 LD_LIBRARY_PATH 中设置
在 /etc/ld.so.conf 文件中设置。
其中，第二种设置方式需要 root 权限，以改变 /etc/ld.so.conf 文件并执行 /sbin/ldconfig 命令。而且，当系统重新启动后，所有的基于 GTK2 的程序在运行时都将使用新安装的 GTK+ 库。不幸的是，由于 GTK+ 版本的改变，这有时会给应用程序带来兼容性的问题，造成某些程序运行不正常。为了避免出现上面的这些情况，在 GTK+ 及其依赖库的安装过程中对于库的搜索路径的设置将采用第一种方式进行。这种设置方式不需要 root 权限，设置也简单：
$ export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH
可以用下面的命令查看 LD_LIBRAY_PATH 的设置内容：
$ echo $LD_LIBRARY_PATH
至此，库的两种设置就完成了。
交叉编译时候如何配置连接库的搜索路径
交叉编译的时候不能使用本地（i686机器，即PC机器，研发机器）机器上的库，但是在做编译链接的时候默认的是使用本地库，即/usr/lib,/lib两个目录。因此，在交叉编译的时候，要采取一些方法使得在编译链接的时候找到需要的库。
首先，要知道：编译的时候只需要头文档，真正实际的库文档在链接的时候用到。 （这是我的理解，假如有不对的地方，敬请网上各位大侠指教） 然后，讲讲如何在交叉编译链接的时候找到需要的库。
（1）、交叉编译时候直接使用-L和-I参数指定搜索非标准的库文档和头文档的路径。例如：
arm-linux-gcc test.c -L/usr/local/arm/2.95.3/arm-linux/lib -I/usr/local/arm/2.95.3/arm-linux/include
（2）、使用ld.so.conf文档，将用到的库所在文档目录添加到此文档中，然后使用ldconfig命令刷新缓存。
（3）、使用如下命令：
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/arm/2.95.3/arm-linux-lib
参见《ld.so.conf 文档和PKG_CONFIG_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环境变量查找。
（4）、交叉编译时使用软件的configure参数。例如我编译minigui-1.3.3，使用如下配置：
#!/bin/bash
rm -f config.cache config.status
./configure --build=i686-linux --host=arm-linux --target=arm-linux /
CFLAGS=-I/usr/local/arm/2.95.3/arm-linux/include /
LDFLAGS=-L/usr/local/arm/2.95.3/arm-linux/lib /
--prefix=/usr/local/arm/2.95.3/arm-linux /
--enable-lite /
--disable-galqvfb /
--disable-qvfbial /
--disable-vbfsupport /
--disable-ttfsupport /
--disable-type1support /
--disable-imegb2312py /
--enable-extfullgif /
--enable-extskin /
--disable-videoqvfb /
--disable-videoecoslcd
这里我配置了CFLAGS和LDFLAGS参数，这样一来，我就不用去修改每个Makefile里-L和-I参数了，也不用再去配置LD_LIBRARY_PATH或改写ld.so.conf文档了。
Linux下动态库使用小结
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.c -Ltools -ltool
编译不报错，但是运行加载的时候就出现cannot open shared object file。
如果将该库文件拷贝到/usr/lib下就没有错误，正常运行。
说明编译时的-L选项并不影响环境变量LD_LIBRARY_PATH，-L只是指定了程序编译连接时库的路径，并不影响程序执行时库的路径，系统还是会到默认路径下查找该程序所需要的库。
有关动态链接库需要注意的相关事项
如果碰到有GTK 的 程序中 有 <gtk/gtk.h>
那么需要加入动态链接库的参数
$ gcc test_a.c test_b.c iptbox.c -fPIC -shared -o iptbox.so `pkg-config --cflags --libs gtk+-2.0
生成出来的.so 动态链接库 需要放在usr/lib 目录下
cp libipt.so /usr/lib
2、在 运行AP时出现错误，可以使用下列方式来查找问题：
strace ./test
3、查找 文件夹下路径：
find /usr/lib -name libipt.so
4、解压缩 命令：
tar -zxvf 文件名
5、解RPM包的方式：
# rpm -ivh scim-1.4.7.4-1benX.src. rpm
#cd /usr/src/dorado/SPECS
#rpmbuild -bb scim.spec
6、目录权限打开：
chmod 777 root(目录名称)
7、linux 下 安装 软件三步骤：
a. ./ configure
b. make
c. make install
8、更新库引用：
ldconfig
9、查找是否有安装该AP.
# whereis scim-ppenglish
136
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
