3.2. How Libraries are Used

1.*.so放入 /lib 或 /etc/lib　　　（放进系统的lib环境变量的目录，否则要自己指定链接的目录）

2./etc/ld.so.conf

3.设置LD_LIBRARY_PATH

下面都会有详细说明

To create a static library, or to add additional object files to an existing static library, use a command like this:

ar rcs my_library.a file1.o file2.o



example:  http://tldp.org/HOWTO/C++-dlopen/examples.tar.gz


http://blog.sina.com.cn/s/blog_4cce4f6a0100ms6f.html

 Linux 共享库
　　Linux 系统上有两类根本不同的 Linux 可执行程序。第一类是静态链接的可执行程序。静态可执行程序包含执行所需的所有函数 — 换句话说，它们是“完整的”。因为这一原因，静态可执行程序不依赖任何外部库就可以运行。
　　第二类是动态链接的可执行程序。
　　静态可执行程序与动态可执行程序比较
　　我们可以用 ldd 命令来确定某一特定可执行程序是否为静态链接的：
　　# ldd /sbin/sln
　　not a dynamic executable
　　“not a dynamic executable”是 ldd 说明 sln 是静态链接的一种方式。现在，让我们比较 sln 与其非静态同类 ln 的大小：
　　# ls -l /bin/ln /sbin/sln
　　-rwxr-xr-x    1 root     root        23000 Jan 14 00:36 /bin/ln
　　-rwxr-xr-x    1 root     root       381072 Jan 14 00:31 /sbin/sln
　　如您所见，sln 的大小超过 ln 十倍。ln 比 sln 小这么多是因为它是动态可执行程序。动态可执行程序是不完整的程序，它依靠外部共享库来提供运行所需的许多函数。
　　动态链接相关性
　　要查看 ln 依赖的所有共享库的列表，可以使用 ldd 命令：
　　# ldd /bin/ln
　　libc.so.6 => /lib/libc.so.6 (0x40021000)
　　/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
　　如您所见，ln 依赖外部共享库 libc.so.6 和 ld-linux.so.2。通常，动态链接的程序比其静态链接的等价程序小得多。不过，静态链接的程序可以在某些低级维护任务中发挥作用。例如，sln 是修改位于 /lib 中的不同库符号链接的极佳工具。但通常您会发现几乎所有 Linux 系统上的可执行程序都是某种动态链接的变体。
　　动态装入器
　　那么，如果动态可执行程序不包含运行所需的所有函数，Linux 的哪部分负责将这些程序和所有必需的共享库一起装入，以使它们能正确执行呢？答案是动态装入器（dynamic loader），它实际上是您在 ln 的 ldd 清单中看到的作为共享库相关性列出的 ld-linux.so.2 库。动态装入器负责装入动态链接的可执行程序运行所需的共享库。现在，让我们迅速查看一下动态装入器如何在系统上找到适当的共享库。
　　ld.so.conf
　　动态装入器找到共享库要依靠两个文件 — /etc/ld.so.conf 和 /etc/ld.so.cache。如果您对 /etc/ld.so.conf 文件进行 cat 操作，您可能会看到一个与下面类似的清单：
　　$ cat /etc/ld.so.conf
　　/usr/X11R6/lib
　　/usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3
　　/usr/lib/mozilla
　　/usr/lib/qt-x11-2.3.1/lib
　　/usr/local/lib
　　ld.so.conf 文件包含一个所有目录（/lib 和 /usr/lib 除外，它们会自动包含在其中）的清单，动态装入器将在其中查找共享库。
　　ld.so.cache
　　但是在动态装入器能“看到”这一信息之前，必须将它转换到 ld.so.cache 文件中。可以通过运行 ldconfig 命令做到这一点：
　　# ldconfig
　　当 ldconfig 操作结束时，您会有一个最新的 /etc/ld.so.cache 文件，它反映您对 /etc/ld.so.conf 所做的更改。从这一刻起，动态装入器在寻找共享库时会查看您在 /etc/ld.so.conf 中指定的所有新目录。
　　ldconfig 技巧
　　要查看 ldconfig 可以“看到”的所有共享库，请输入：
　　# ldconfig -p | less
　　还有另一个方便的技巧可以用来配置共享库路径。有时候您希望告诉动态装入器在尝试任何 /etc/ld.so.conf 路径以前先尝试使用特定目录中的共享库。在您运行的较旧的应用程序不能与当前安装的库版本一起工作的情况下，这会比较方便。
　　LD_LIBRARY_PATH
　　要指示动态装入器首先检查某个目录，请将 LD_LIBRARY_PATH 变量设置成您希望搜索的目录。多个路径之间用冒号分隔；例如：
　　# export LD_LIBRARY_PATH="/usr/lib/old:/opt/lib"
　　导出 LD_LIBRARY_PATH 后，如有可能，所有从当前 shell 启动的可执行程序都将使用 /usr/lib/old 或 /opt/lib 中的库，如果仍不能满足一些共享库相关性要求，则转回到 /etc/ld.so.conf 中指定的库。

View Code

C++ 静态库与动态库

这次分享的宗旨是——让大家学会创建与使用静态库、动态库，知道静态库与动态库的区别，知道使用的时候如何选择。这里不深入介绍静态库、动态库的底层格式，内存布局等，有兴趣的同学，推荐一本书《程序员的自我修养——链接、装载与库》。

库是写好的现有的，成熟的，可以复用的代码。 现实中每个程序都要依赖很多基础的底层库，不可能每个人的代码都从零开始，因此库的存在意义非同寻常 。

本质上来说库是一种可执行代码的二进制形式，可以被操作系统载入内存执行。库有两种：静态库（ .a 、 .lib ）和动态库（ .so 、 .dll ）。

所谓静态、动态是指链接。回顾一下，将一个程序编译成可执行程序的步骤：

图：编译过程

之所以成为【静态库】，是因为在链接阶段，会将汇编生成的目标文件 .o 与引用到的库一起链接打包到可执行文件中。因此对应的链接方式称为静态链接。

试想一下，静态库与汇编生成的目标文件一起链接为可执行文件，那么静态库必定跟 .o 文件格式相似。其实一个静态库可以简单看成是 一组目标文件（ .o/.obj 文件）的集合 ，即很多目标文件经过压缩打包后形成的一个文件。静态库特点总结：

l 静态库对函数库的链接是放在编译时期完成的。

l 程序在运行时与函数库再无瓜葛，移植方便。

l 浪费空间和资源，因为所有相关的目标文件与牵涉到的函数库被链接合成一个可执行文件。

下面编写一些简单的四则运算 C++ 类，将其编译成静态库给他人用，头文件如下所示：

static double add( double a, double b); // 加法

static double sub( double a, double b); // 减法

static double mul( double a, double b); // 乘法

static double div( double a, double b); // 除法

void print();

Linux 下使用 ar 工具、 Windows 下 vs 使用 lib.exe ，将目标文件压缩到一起，并且对其进行编号和索引，以便于查找和检索。一般创建静态库的步骤如图所示：

图：创建静态库过程

Linux 下创建与使用静态库

Linux 静态库命名规则

Linux 静态库命名规范，必须是 "lib[your_library_name].a" ： lib 为前缀，中间是静态库名，扩展名为 .a 。

创建静态库（ .a ）

通过上面的流程可以知道， Linux 创建静态库过程如下：

l 首先，将代码文件编译成目标文件 .o （ StaticMath.o ）

cout << "a + b = " << StaticMath ::add(a, b) << endl;

cout << "a - b = " << StaticMath ::sub(a, b) << endl;

cout << "a * b = " << StaticMath ::mul(a, b) << endl;

cout << "a / b = " << StaticMath ::div(a, b) << endl;

StaticMath sm;

sm.print();

system( "pause" );

return 0;

Linux 下使用静态库，只需要在编译的时候，指定静态库的搜索路径（ -L 选项）、指定静态库名（不需要 lib 前缀和 .a 后缀， -l 选项）。

# g++ TestStaticLibrary.cpp - L../StaticLibrary -lstaticmath

l -L ：表示要连接的库所在目录

l -l ：指定链接时需要的动态库，编译器查找动态连接库时有隐含的命名规则，即在给出的名字前面加上 lib ，后面加上 .a 或 .so 来确定库的名称。

可以把链接的静态库[路径]和[名字] 补齐， g++ TestStaticLibrary.cpp - L../StaticLibrary libstaticmath.a

Windows 下创建与使用静态库

创建静态库（ .lib ）

如果是使用 VS 命令行生成静态库，也是分两个步骤来生成程序：

l 首先，通过使用带编译器选项 /c 的 Cl.exe 编译代码 ( cl /c StaticMath.cpp ) ，创建名为 “StaticMath.obj” 的目标文件。

l 然后，使用库管理器 Lib.exe 链接代码 ( lib StaticMath.obj ) ，创建静态库 StaticMath.lib 。

当然，我们一般不这么用，使用 VS 工程设置更方便。创建 win32 控制台程序时，勾选静态库类型；打开工程 “ 属性面板 ” è ” 配置属性 ” è ” 常规 ” ，配置类型选择静态库。

图： vs 静态库项目属性设置

Build 项目即可生成静态库。

使用静态库

测试代码 Linux 下面的一样。有 3 种使用方法：

在 VS 中使用静态库方法：

l 工程 “ 属性面板 ” -> “ 通用属性 ” -> “ 框架和引用 ” -> ” 添加引用 ” ，将显示 “ 添加引用 ” 对话框。 “ 项目 ” 选项卡列出了当前解决方案中的各个项目以及可以引用的所有库。在 “ 项目 ” 选项卡中，选择 StaticLibrary 。单击 “ 确定 ” 。

l 添加 StaticMath.h 头文件目录，必须修改包含目录路径。打开工程 “ 属性面板 ” -> ” 配置属性 ” -> “C/C++” -> ” 常规 ” ，在 “ 附加包含目录 ” 属性值中，键入 StaticMath.h 头文件所在目录的路径或浏览至该目录。

编译运行 OK 。

图：静态库测试结果（ vs ）

如果引用的静态库不是在同一解决方案下的子工程，而是使用第三方提供的静态库 lib 和头文件，上面的方法设置不了。还有 2 中方法设置都可行。

打开工程 “ 属性面板 ” -> ” 配置属性 ” -> “ 链接器 ” -> ” 命令行 ” ，输入静态库的完整路径即可。

l “ 属性面板 ” -> ” 配置属性 ” -> “ 链接器 ” -> ” 常规 ” ，附加依赖库目录中输入，静态库所在目录；

l “ 属性面板 ” -> ” 配置属性 ” -> “ 链接器 ” -> ” 输入 ” ，附加依赖库中输入静态库名 StaticLibrary.lib 。

通过上面的介绍发现静态库，容易使用和理解，也达到了代码复用的目的，那为什么还需要动态库呢？

为什么还需要动态库？

为什么需要动态库，其实也是静态库的特点导致。

l 空间浪费是静态库的一个问题。

l 另一个问题是静态库对程序的更新、部署和发布页会带来麻烦。如果静态库 liba.lib 更新了，所以使用它的应用程序都需要重新编译、发布给用户（对于玩家来说，可能是一个很小的改动，却导致整个程序重新下载， 全量更新 ）。

动态库在程序编译时并不会被连接到目标代码中，而是在程序运行是才被载入。 不同的应用程序如果调用相同的库，那么在内存里只需要有一份该共享库的实例 ，规避了空间浪费问题。动态库在程序运行是才被载入，也解决了静态库对程序的更新、部署和发布页会带来麻烦。用户只需要更新动态库即可， 增量更新 。

动态库特点总结：

l 动态库把对一些库函数的链接载入推迟到程序运行的时期。

l 可以实现进程之间的资源共享。（因此动态库也称为共享库）

l 将一些程序升级变得简单。

l 甚至可以真正做到链接载入完全由程序员在程序代码中控制（ 显示调用 ）。

Window 与 Linux 执行文件格式不同，在创建动态库的时候有一些差异。

l 在 Windows 系统下的执行文件格式是 PE 格式，动态库需要一个 DllMain 函数做出初始化的入口，通常在导出函数的声明时需要有 _declspec(dllexport) 关键字 。

l Linux 下 gcc 编译的执行文件默认是 ELF 格式， 不需要初始化入口，亦不需要函数做特别的声明， 编写比较方便。

与创建静态库不同的是，不需要打包工具（ ar 、 lib.exe ），直接使用编译器即可创建动态库。

Linux 下创建与使用动态库

linux 动态库的命名规则

动态链接库的名字形式为 libxxx.so ，前缀是 lib ，后缀名为“ .so ”。

l 针对于实际库文件，每个共享库都有个特殊的名字“ soname ”。在程序启动后，程序通过这个名字来告诉动态加载器该载入哪个共享库。

l 在文件系统中， soname 仅是一个链接到实际动态库的链接。对于动态库而言，每个库实际上都有另一个名字给编译器来用。它是一个指向实际库镜像文件的链接文件（ lib+soname+.so ）。

创建动态库（ .so ）

编写四则运算动态库代码：

static double add(double a, double b);//¼Ó·¨

static double sub(double a, double b);//¼õ·¨

static double mul(double a, double b);//³Ë·¨

static double div(double a, double b);//³ý·¨

void print();

cout << "a + b = " << DynamicMath::add(a, b) << endl;

cout << "a - b = " << DynamicMath::sub(a, b) << endl;

cout << "a * b = " << DynamicMath::mul(a, b) << endl;

cout << "a / b = " << DynamicMath::div(a, b) << endl;

DynamicMath dyn;

dyn.print();

return 0;

发现还是报错！！！那么，在执行的时候是如何定位共享库文件的呢？

1) 当系统加载可执行代码时候，能够知道其所依赖的库的名字，但是还需要知道绝对路径。此时就需要系统动态载入器 (dynamic linker/loader) 。

2) 对于 elf 格式的可执行程序，是由 ld-linux.so* 来完成的，它先后搜索 elf 文件的 DT_RPATH 段—环境变量 LD_LIBRARY_PATH — /etc/ld.so.cache 文件列表— /lib/,/usr/lib 目录找到库文件后将其载入内存。

如何让系统能够找到它：

l 如果安装在 /lib 或者 /usr/lib 下，那么 ld 默认能够找到，无需其他操作。

l 如果安装在其他目录，需要将其添加到 /etc/ld.so.cache 文件中，步骤如下：

n 编辑 /etc/ld.so.conf 文件，加入库文件所在目录的路径（比如我libev的静态库默认安装在/usr/local/lib, 那就添加这行 inlcude /usr/local/lib）

n 运行 ldconfig ，该命令会重建 /etc/ld.so.cache 文件

我们将创建的动态库复制到 /usr/lib 下面，然后运行测试程序。

最好把链接的动态库的【路径】和【名字】补齐， g++ TestDynamicLibrary.cpp -L/usr/local/lib /usr/local/lib/libdynmath.so

http://www.linuxidc.com/Linux/2012-12/76632.htm

注: 有时候用户想知道系统中有哪些动态链接库,或者想知道系统中有没有某个动态链接库,

这时,可用-p选项让ldconfig输出缓存文件中的动态链接库列表,从而查询得到.

# ldconfig -p

//找不到我们新安装的动态库？没关系用这个个命令刷新动态库信息

#ldconfig

// /sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied 提示权限不够，

#sudo ldconfig

//搞定，可以找到新安装的*.so 动态库了

注: ldconfig命令在运行正常的情况下,默认不输出什么东西.本例中用了-v选项,以使ldconfig在运行时输出正在扫描的目录及搜索到的共享库, 用户可以清楚地看到运行的结果.执行结束后,ldconfig将刷新缓存文件/etc/ld.so.cache.

ldconfig几个需要注意的地方
1. 往/lib和/usr/lib里面加东西，是不用修改/etc/ld.so.conf的，但是完了之后要调一下ldconfig，不然这个library会找不到
2. 想往上面两个目录以外加东西的时候，一定要修改/etc/ld.so.conf，然后再调用ldconfig，不然也会找不到
比如安装了一个mysql到/usr/local/mysql，mysql有一大堆library在 /usr/local/mysql/lib下面，这时就需要在/etc/ld.so.conf下面加一行/usr/local/mysql/lib，保存过后ldconfig一下，新的library才能在程序运行时被找到。
3. 如果想在这两个目录以外放lib，但是又不想在/etc/ld.so.conf中加东西（或者是没有权限加东西）。那也可以，就是export一个全局变量LD_LIBRARY_PATH，然后运行程序的时候就会去这个目录中找library。一般来讲这只是一种临时的解决方案，在没有权限或临时需要的时候使用。
4. ldconfig做的这些东西都与运行程序时有关，跟编译时一点关系都没有。编译的时候还是该加-L就得加，不要混淆了。
5. 总之，就是不管做了什么关于library的变动后，最好都ldconfig一下，不然会出现一些意想不到的结果。不会花太多的时间，但是会省很多的事。

=====================================

Windows 下创建与使用动态库

创建动态库（ .dll ）

与 Linux 相比，在 Windows 系统下创建动态库要稍微麻烦一些。首先，需要一个 DllMain 函数做出初始化的入口（创建 win32 控制台程序时，勾选 DLL 类型会自动生成这个文件）：

public :

__declspec ( dllexport ) DynamicMath( void );

__declspec ( dllexport ) ~DynamicMath( void );

static __declspec ( dllexport ) double add( double a, double b); // 加法

static __declspec ( dllexport ) double sub( double a, double b); // 减法

static __declspec ( dllexport ) double mul( double a, double b); // 乘法

static __declspec ( dllexport ) double div( double a, double b); // 除法

__declspec ( dllexport ) void print();

cout << "a + b = " << DynamicMath ::add(a, b) << endl;

cout << "a - b = " << DynamicMath ::sub(a, b) << endl;

cout << "a * b = " << DynamicMath ::mul(a, b) << endl;

cout << "a / b = " << DynamicMath ::div(a, b) << endl;

DynamicMath dyn;

dyn.print();

system( "pause" );

return 0;

l 工程 “ 属性面板 ” è “ 通用属性 ” è “ 框架和引用 ” è ” 添加引用 ” ，将显示 “ 添加引用 ” 对话框。 “ 项目 ” 选项卡列出了当前解决方案中的各个项目以及可以引用的所有库。在 “ 项目 ” 选项卡中，选择 DynamicLibrary 。单击 “ 确定 ” 。

l 添加 DynamicMath.h 头文件目录，必须修改包含目录路径。打开工程 “ 属性面板 ” è ” 配置属性 ” è “C/C++” è ” 常规 ” ，在 “ 附加包含目录 ” 属性值中，键入 DynamicMath.h 头文件所在目录的路径或浏览至该目录。

编译运行 OK 。

图：动态库测试结果（ vs ）

l “ 属性面板 ” -> ” 配置属性 ” -> “ 链接器 ” -> ” 常规 ” ，附加依赖库目录中输入，动态库所在目录；

l “ 属性面板 ” -> ” 配置属性 ” -> “ 链接器 ” -> ” 输入 ” ，附加依赖库中输入动态库编译出来的 DynamicLibrary.lib 。

这里可能大家有个疑问，动态库怎么还有一个 DynamicLibrary.lib 文件？即无论是静态链接库还是动态链接库，最后都有 lib 文件，那么两者区别是什么呢？其实，两个是完全不一样的东西。

StaticLibrary.lib 的大小为 190KB ， DynamicLibrary.lib 的大小为 3KB ，静态库对应的 lib 文件叫 静态库 ，动态库对应的 lib 文件叫【 导入库】 。实际上静态库本身就包含了实际执行代码、符号表等等，而 对于导入库而言，其实际的执行代码位于动态库中，导入库只包含了地址符号表等，确保程序找到对应函数的一些基本地址信息 。

上面介绍的动态库使用方法和静态库类似属于隐式调用，编译的时候指定相应的库和查找路径。其实，动态库还可以显式调用。【在 C 语言中】 ，显示调用一个动态库轻而易举！

在 Linux 下显式调用动态库

#include <dlfcn.h> ，提供了下面几个接口：

l void * dlopen ( const char * pathname, int mode ) ：函数以指定模式打开指定的动态连接库文件，并返回一个句柄给调用进程。

l void* dlsym (void* handle,const char* symbol) ： dlsym 根据动态链接库操作句柄 (pHandle) 与符号 (symbol) ，返回符号对应的地址。使用这个函数不但可以获取函数地址，也可以获取变量地址。

l int dlclose (void *handle) ： dlclose 用于关闭指定句柄的动态链接库，只有当此动态链接库的使用计数为 0 时 , 才会真正被系统卸载。

l const char *dlerror(void) ：当动态链接库操作函数执行失败时， dlerror 可以返回出错信息，返回值为 NULL 时表示操作函数执行成功。

在 Windows 下显式调用动态库

应用程序必须进行函数调用以在运行时显式加载 DLL 。为显式链接到 DLL ，应用程序必须：

l 调用 LoadLibrary （或相似的函数）以加载 DLL 和获取模块句柄。

l 调用 GetProcAddress ，以获取指向应用程序要调用的每个导出函数的函数指针。由于应用程序是通过指针调用 DLL 的函数，编译器不生成外部引用，故无需与导入库链接。

l 使用完 DLL 后调用 FreeLibrary 。

显式调用 C++ 动态库注意点

对 C++ 来说，情况稍微复杂。显式加载一个 C++ 动态库的困难 一部分是因为 C++ 的 name mangling ； 另一部分是因为没有提供一个合适的 API 来装载类 ，在 C++ 中，您可能要用到库中的一个类，而这需要创建该类的一个实例，这不容易做到。

name mangling 可以通过 extern "C" 解决。 C++ 有个特定的关键字用来声明采用 C binding 的函数： extern "C" 。用 extern "C" 声明的函数将使用函数名作符号名，就像 C 函数一样。因此，只有非成员函数才能被声明为 extern "C" ，并且不能被重载。尽管限制多多， extern "C" 函数还是非常有用，因为它们可以象 C 函数一样被 dlopen 动态加载。冠以 extern "C" 限定符后，并不意味着函数中无法使用 C++ 代码了，相反，它仍然是一个完全的 C++ 函数，可以使用任何 C++ 特性和各种类型的参数。

另外如何从 C++ 动态库中获取类，附上几篇相关文章，但我并不建议这么做：

l 《 LoadLibrary 调用 DLL 中的 Class 》： http://www.cppblog.com/codejie/archive/2009/09/24/97141.html

l 《 C++ dlopen mini HOWTO 》： http://blog.csdn.net/denny_233/article/details/7255673

“显式”使用 C++ 动态库中的 Class 是非常繁琐和危险的事情，因此能用“隐式”就不要用“显式”，能静态就不要用动态。

附件： Linux 下库相关命令

l -shared ：指定生成动态链接库。

l -static ：指定生成静态链接库。

l -fPIC ：表示编译为位置独立的代码，用于编译共享库。目标文件需要创建成位置无关码，念上就是在可执行程序装载它们的时候，它们可以放在可执行程序的内存里的任何地方。

l -L. ：表示要连接的库所在的目录。

l -l ：指定链接时需要的动态库。编译器查找动态连接库时有隐含的命名规则，即在给出的名字前面加上 lib ，后面加上 .a/.so 来确定库的名称。

l -Wall ：生成所有警告信息。

l -ggdb ：此选项将尽可能的生成 gdb 的可以使用的调试信息。

l -g ：编译器在编译的时候产生调试信息。

l -c ：只激活预处理、编译和汇编 , 也就是把程序做成目标文件 (.o 文件 ) 。

l -Wl,options ：把参数 (options) 传递给链接器 ld 。如果 options 中间有逗号 , 就将 options 分成多个选项 , 然后传递给链接程序。

nm 命令

有时候可能需要查看一个库中到底有哪些函数， nm 命令可以打印出库中的涉及到的所有符号。库既可以是静态的也可以是动态的。 nm 列出的符号有很多，常见的有三种：

l 一种是在库中被调用，但并没有在库中定义 ( 表明需要其他库支持 ) ，用 U 表示；

l 一种是库中定义的函数，用 T 表示，这是最常见的；

l 一种是所谓的弱态”符号，它们虽然在库中被定义，但是可能被其他库中的同名符号覆盖，用 W 表示。

$nm libhello.h

ldd 命令

ldd 命令可以查看一个可执行程序依赖的共享库 ，例如我们编写的四则运算动态库依赖下面这些库：

二者的不同点在于 代码被载入的时刻不同 。

l 静态库在程序编译时会被连接到目标代码中，程序运行时将不再需要该静态库， 因此体积较大 。（ 转载者说下，还有一个是静态库包含了依赖，而动态库没有 ）

l 动态库在程序编译时并不会被连接到目标代码中，而是在程序运行是才被载入，因此在程序运行时还需要动态库存在， 因此代码体积较小 。

动态库的好处是，不同的应用程序如果调用相同的库，那么在内存里只需要有一份该共享库的实例。带来好处的同时，也会有问题！如经典的 DLL Hell 问题，关于如何规避动态库管理问题，可以自行查找相关资料。

动态库加载路径之RPATH与RUNPATH(小记) http://blog.csdn.net/dbzhang800/article/details/6918413

自己指定路径

gcc -o libevTest libevTest.c -L/usr/local/lib -lev -Wl,--rpath=/usr/local/lib

放到当前路径

gcc -o libevTest libevTest.c -L. -lev -Wl,--rpath=.

windows 显式链接lib

//libxl
#include "../include_cpp/libxl.h"
#pragma comment(lib,"../lib/libxl.lib")
using namespace libxl;

#include <WINSOCK2.H>
#include <process.h>
#include <Iphlpapi.h>
#pragma comment(lib,"Ws2_32.lib")
#pragma comment(lib,"Iphlpapi.lib")

#include<vector>
using namespace std;

#define SAFE_DELETE_ELEMENT(ptr) \
if (ptr != NULL)      \
{                     \
delete ptr;       \
ptr = NULL;       \
}

#define SAFE_DELETE_ARRAY(ptr) \
if (ptr != NULL)            \
{                           \
delete[] ptr;           \
ptr = NULL;             \
}

如果我们要link x86、x64的debug,release库，从工程文件中难免会出错。写在文件中一目了然，错误的概率自然小了很多。

1.设置头文件的路径 [additional include directories]

2.设置静态库的路径 [additional library directories]

vs2015 的#para comment （lib,""）不支持写入路径了，只能写文件。

所以只能在工程目录中设置library的路径。

下面是x86的

3. 需要特别注意的是 Runtime Library ：

Multi-threaded (/MT)

Multi-threaded Debug (/MTd) （如果是动态库的话，设置/MD /MDd）

#ifdef _DEBUG
#pragma comment(lib, "CppUnitmtd.lib")
#pragma comment(lib, "PocoFoundationmtd.lib")
#pragma comment(lib, "PocoJSONmtd.lib")
#pragma comment(lib, "PocoNetmtd.lib")
#pragma comment(lib, "PocoUtilmtd.lib")
#pragma comment(lib, "PocoXMLmtd.lib")
#else  //release
#pragma comment(lib, "CppUnitmt.lib")
#pragma comment(lib, "PocoFoundationmt.lib")
#pragma comment(lib, "PocoJSONmt.lib")
#pragma comment(lib, "PocoNetmt.lib")
#pragma comment(lib, "PocoUtilmt.lib")
#pragma comment(lib, "PocoXMLmt.lib")
#endif // _DEBUG
#ifdef WIN32
    #ifdef _DEBUG
        #pragma comment(lib, "..\\lib\\Poco\\x86\\mtd\\CppUnitmtd.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x86\\mtd\\PocoFoundationmtd.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x86\\mtd\\PocoJSONmtd.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x86\\mtd\\PocoNetmtd.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x86\\mtd\\PocoUtilmtd.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x86\\mtd\\PocoXMLmtd.lib")
    #else  //release
        #pragma comment(lib, "..\\lib\\Poco\\x86\\mt\\CppUnitmt.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x86\\mt\\PocoFoundationmt.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x86\\mt\\PocoJSONmt.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x86\\mt\\PocoNetmt.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x86\\mt\\PocoUtilmt.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x86\\mt\\PocoXMLmt.lib")
    #endif // _DEBUG
#else //x64
    #ifdef _DEBUG
        #pragma comment(lib, "..\\lib\\Poco\\x64\\mtd\\CppUnitmtd.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x64\\mtd\\PocoFoundationmtd.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x64\\mtd\\PocoJSONmtd.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x64\\mtd\\PocoNetmtd.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x64\\mtd\\PocoUtilmtd.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x64\\mtd\\PocoXMLmtd.lib")
    #else  //release
        #pragma comment(lib, "..\\lib\\Poco\\x64\\mt\\CppUnitmt.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x64\\mt\\PocoFoundationmt.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x64\\mt\\PocoJSONmt.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x64\\mt\\PocoNetmt.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x64\\mt\\PocoUtilmt.lib")
        #pragma comment(lib, "..\\lib\\Poco\\x64\\mt\\PocoXMLmt.lib")
    #endif // _DEBUG
#endif
load library 宏