Linux库有动态与静态两种，动态通常用.so为后缀，静态用.a为后缀。例如：libhello.so libhello.a
为了在同一系统中使用不同版本的库，可以在库文件名后加上版本号为后缀,例如： libhello.so.1.0,由于程序连接默认以.so为文件后缀名。所以为了使用这些库，通常使用建立符号连接的方式。
ln -s libhello.so.1.0 libhello.so.1
ln -s libhello.so.1 libhello.so
动态库和静态库的区别：
当要使用静态的程序库时，连接器会找出程序所需的函数，然后将它们拷贝到执行文件，由于这种拷贝是完整的，所以一旦连接成功，静态程序库也就不再需要了。然而，对动态库而言，就不是这样。动态库会在执行程序内留下一个标记‘指明当程序执行时，首先必须载入这个库。由于动态库节省空间，linux下进行连接的缺省操作是首先连接动态库，也就是说，如果同时存在静态和动态库，不特别指定的话，将与动态库相连接。
两种库的编译产生方法：
第一步要把源代码编绎成目标代码。以下面的代码hello.c为例，生成hello库：
/* hello.c */
#include
void sayhello()
{
printf("hello,world\n");
}
用gcc编绎该文件，在编绎时可以使用任何全法的编绎参数，例如-g加入调试代码等：
gcc -c hello.c -o hello.o
1.连接成静态库
连接成静态库使用ar命令，其实ar是archive的意思
$ar cqs libhello.a hello.o
2.连接成动态库
生成动态库用gcc来完成，由于可能存在多个版本，因此通常指定版本号：
$gcc -shared -Wl,-soname,libhello.so.1 -o libhello.so.1.0 hello.o
另外再建立两个符号连接：
$ln -s libhello.so.1.0 libhello.so.1
$ln -s libhello.so.1 libhello.so
这样一个libhello的动态连接库就生成了。最重要的是传gcc -shared 参数使其生成是动态库而不是普通执行程序。
-Wl 表示后面的参数也就是-soname,libhello.so.1直接传给连接器ld进行处理。实际上，每一个库都有一个soname，当连接器发现它正在查找的程序库中有这样一个名称，连接器便会将soname嵌入连结中的二进制文件内，而不是它正在运行的实际文件名，在程序执行期间，程序会查找拥有 soname名字的文件，%B
㈡ 什么叫静态库和动态库
两者区别：
一，静态库的使用需要：
1
包含一个对应的头文件告知编译器lib文件里面的具体内容
2
设置lib文件允许编译器去查找已经编译好的二进制代码
二，动态库的使用：
程序运行时需要加载动态库，对动态库有依赖性，需要手动加入动态库
三，依赖性：
静态链接表示静态性，在编译链接之后，
lib库中需要的资源已经在可执行程序中了，
也就是静态存在，没有依赖性了
动态，就是实时性，在运行的时候载入需要的资源，那么必须在运行的时候提供
需要的
动态库，有依赖性，
运行时候没有找到库就不能运行了
四，区别：
简单讲，静态库就是直接将需要的代码连接进可执行程序；动态库就是在需要调用其中的函数时，根据函数映射表找到该函数然后调入堆栈执行。
做成静态库可执行文件本身比较大，但不必附带动态库
做成动态库可执行文件本身比较小，但需要附带动态库
五：
首先纠正所谓“静态连接就是把需要的库函数放进你的exe之中”的说法。在真实世界中，有三个概念：use
static
libary,
static
linked
dll,
dynamic
linked
dll.
多数人混淆了static
libary
和
static
linked
dll的概念，当然他们有似是而非的“相似之处”，比如都用到.lib，下面具体说明。
使用静态库(use
static
libary)是把.lib和其他.obj一起build在目标文件中，目标文件可以是.exe,也可以是.dll或.oxc等。一般情况下，可以根本就没有“对应的”.dll
文件，如c
run
time(crt)库。一个例子就是，写一个main(){}，build出来并不是只有几个字节，当然有人会说那还有exe文件头呢？是，即使加上文件头的尺寸，build出的执行文件仍然“莫名的大”。实际上那多出来的部分就是crt静态库。姑且可以把静态库.lib理解成外部程序的obj文件比较合理，它包含了函数的实现。
㈢ 如何使用lame源代码在编译生成linux环境下的动态库
动态库的生成
1>首先生成目标文件，但是此时要加编译器选项-fpic和链接器选项-shared，
gcc -fpic -c add.c
gcc -fpic -c sub.c
生成中间文件add.o和sub.o
2>其次生成动态库
gcc -shared –o libtiger.so add.o sub.o
生成动态库libtiger.so,libtiger.so就是我们生成的目标动态库。我们以后使用动态库和main.c程序生成可执行程序
说明：
以上两部也可以合成一步搞定:
gcc -fpic -shared add.c sub.c -o libtiger.so
2.使用动态链接库
在编译程序时，使用动态链接库和静态库是一致的，使用”-l库名”的方式，在生成可执行文件的时候会链接库文件。
1>使用命令：
gcc -o main main.c -L ./ -ltiger
2>-L指定动态链接库的路劲，-ldtiger链接库函数tiger。-ltiger是动态库的调用规则。Linux系统下的动态库命名方式是lib*.so,而在链接时表示位-l*,*是自己命名的库名。
3>但是程序会提示如下错误
error while loading shared libraries: libtiger.so: cannot open shared object file: No such file or direct
这是因为程序运行时没有找到动态链接库造成的。程序编译时链接动态库和运行时使用动态链接库的概念是不同的，在运行时，程序链接的动态链接库需要在系统目录下才行。
4>使用以下方法可以解决此问题
a. 在linux下最方便的解决方案是拷贝libtiger.so到绝对目录 /lib 下(但是,要是超级用户才可以，因此要使用sudo哦，亲)。就可以生成可执行程序了
b.第二种方法是：将动态链接库的目录放到程序搜索路径中，可以将库的路径加到环境变量LD_LIBRARY_PATH中实现：
export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH
㈣ 简述gcc编译时使用静态库和动态库的区别
函数库分为静态库和动态库两
种。静态库在程序编译时会被连接到目标代码中，程序运行时将不再需要该静态库。动态
库在程序编译时并不会被连接到目标代码中，而是在程序运行是才被载入，因此在程序运
行时还需要动态库存在。
㈤ 如何编译C/Fortran动态/静态链接库
首先，传统的编译，也就是
静态编译
是把
源文件
翻译成目标文件，这个是一次性过程，也就是你所谓的静态编译。
后来的Java和.NET等语言，首先编译成中间形式，然后运行过程中根据需要编译成本地代码（注意这个过程不是一次性的，下次运行重新编译），这个就是JIT（即时编译）技术，从即时编译发展出了动态编译技术
————————————
（传统的）编译完成后，像C/C++、Fortran、汇编等语言，可以把多个目标文件合并到一个
库文件
中，这个就是静态库。比如常说的
库函数
printf就是libc里面的函数。
如果有了启动函数（main），main里面使用了printf，就可以通过
静态链接
技术，从libc中提取出printf所在的文件加入到可执行文件中，如果printf还需要其它函数，就继续搜索并加入列表，直到形成一个
闭包
。这个就是静态链接。
可是静态链接有个明显的缺点，如果每个程序都需要printf，那么printf这个函数的代码就会同时存在在每个程序中，这样也太占地方了吧。所以发明了动态连接技术，其实有两种形式。无论哪一种，都是首先记录下需要调用printf这个函数以及所在的
动态库
，等到运行的时候再加载动态库，从动态库中找到真正的printf去执行。
由于，
动态链接
技术需要一些额外的信息，传统的静态库是不具备的，这些额外信息主要是重复加载和卸载时所需要的一些代码，因此需要
动态链接库
。
㈥ 关于动态库 静态库 区别与使用 路径查找等
一、引言
我们通常把一些公用函数制作成函数库，供其它程序使用。
函数库分为静态库和动态库两种。
通常情况下，对函数库的链接是放在编译时期（compile time）完成的。所有相关的对象文件（object file）与牵涉到的函数库（library）被链接合成一个可执行文件（executable file）。程序在运行时，与函数库再无瓜葛，因为所有需要的函数已拷贝到相应目录下下。所以这些函数库被成为静态库（static libaray），通常文件名为“libxxx.a”的形式。
其实，我们也可以把对一些库函数的链接载入推迟到程序运行的时期（runtime）。这就是动态链接库（dynamic link library）技术。
二、两者区别：
a，静态库的使用需要：
1 包含一个对应的头文件告知编译器lib文件里面的具体内容
2 设置lib文件允许编译器去查找已经编译好的二进制代码
b，动态库的使用：
程序运行时需要加载动态库，对动态库有依赖性，需要手动加入动态库
c，依赖性：
静态链接表示静态性，在编译链接之后， lib库中需要的资源已经在可执行程序中了， 也就是静态存在，没有依赖性了
动态，就是实时性，在运行的时候载入需要的资源，那么必须在运行的时候提供 需要的 动态库，有依赖性， 运行时候没有找到库就不能运行了
d，区别：
简单讲，静态库就是直接将需要的代码连接进可执行程序；动态库就是在需要调用其中的函数时，根据函数映射表找到该函数然后调入堆栈执行。
做成静态库可执行文件本身比较大，但不必附带动态库
做成动态库可执行文件本身比较小，但需要附带动态库
链接静态库，编译的可执行文件比较大，当然可以用strip命令精简一下（如：strip libtest.a），但还是要比链接动态库的可执行文件大。程序运行时间速度稍微快一点。
静态库是程序运行的时候已经调入内存，不管有没有调用，都会在内存里头。静态库在程序编译时会被连接到目标代码中，程序运行时将不再需要该静态库。
其在编译程序时若链接,程序运行时会在系统指定的路径下搜索，然后导入内存，程序一般执行时间稍微长一点，但编译的可执行文件比较小；动态库是程序运行的时候需要调用的时候才装入内存，不需要的时候是不会装入内存的。
动态库在程序编译时并不会被连接到目标代码中，而是在程序运行是才被载入，因此在程序运行时还需要动态库存在。
三、动态链接库的特点与优势
首先让我们来看一下，把库函数推迟到程序运行时期载入的好处：
1. 可以实现进程之间的资源共享。
什么概念呢？就是说，某个程序的在运行中要调用某个动态链接库函数的时候，操作系统首先会查看所有正在运行的程序，看在内存里是否已有此库函数的拷贝了。如果有，则让其共享那一个拷贝；只有没有才链接载入。这样的模式虽然会带来一些“动态链接”额外的开销，却大大的节省了系统的内存资源。C的标准库就是动态链接库，也就是说系统中所有运行的程序共享着同一个C标准库的代码段。
2. 将一些程序升级变得简单。用户只需要升级动态链接库，而无需重新编译链接其他原有的代码就可以完成整个程序的升级。Windows 就是一个很好的例子。
3. 甚至可以真正坐到链接载入完全由程序员在程序代码中控制。
程序员在编写程序的时候，可以明确的指明什么时候或者什么情况下，链接载入哪个动态链接库函数。你可以有一个相当大的软件，但每次运行的时候，由于不同的操作需求，只有一小部分程序被载入内存。所有的函数本着“有需求才调入”的原则，于是大大节省了系统资源。比如现在的软件通常都能打开若干种不同类型的文件，这些读写操作通常都用动态链接库来实现。在一次运行当中，一般只有一种类型的文件将会被打开。所以直到程序知道文件的类型以后再载入相应的读写函数，而不是一开始就将所有的读写函数都载入，然后才发觉在整个程序中根本没有用到它们。
静态库：在编译的时候加载生成目标文件，在运行时不用加载库，在运行时对库没有依赖性。
动态库：在目标文件运行时加载，手动加载，且对库有依赖性。
具体在开发中用到哪种库，我觉得还是根据实际的内存大小，ROM大小，运行的速度等综合考虑。
㈦ 如何编译&使用boost库
1. 编译
1.2. VS2005编译boost_1_55_0
1.2.1. 使用vs2005的命令行执行：...\boost_1_55_0\bootstrap.bat
1.2.2. 编译动态库
bjam install stage --toolset=msvc-8.0 --stagedir="C:\Boost\boost_vc_80" link=shared runtime-link=shared threading=multi debug release
1.2.3. 编译静态库
bjam install stage --toolset=msvc-8.0 --stagedir="D:\Boost\boost_vc_80" link=static runtime-link=static threading=multi debug release
各种参数详解：
stage：表示只生成库（dll和lib）
install：还会生出包含的头文件
--toolset=msvc-8.0：指定编译器版本，8.0为vs2005，其他VS类推。
--stagedir：指定编译后存放的目录
link：生成动态库/静态库。动态库（shared），静态库（static）
runtime-link：动态/静态C/C++运行时库，同样有shared和static两种组合方式。这样共有4种组合方式，个人根据自己需要选择。
threading：单/多线程，一般都是多线程程序，当然multi了。
debug/release：编译版本，一般2个都需要。
2. 使用
使用静态库：
[cpp] view plain print?
//#define BOOST_ALL_DYN_LINK
#include <boost/bind.hpp>
#include <boost/asio.hpp>
#include <boost/thread/thread.hpp>
#include <boost/thread/mutex.hpp>
#include <boost/thread/condition.hpp>
使用静态库连接时，仅需要包含的lib为：
debug版：libboost_system-vc80-mt-gd-1_55.lib等一系列包含gd的库。
release版本：libboost_system-vc80-mt-1_55.lib等一系列不包含gd的库。
使用动态库链接：
[cpp] view plain print?
#define BOOST_ALL_DYN_LINK
#include <boost/bind.hpp>
#include <boost/asio.hpp>
#include <boost/thread/thread.hpp>
#include <boost/thread/mutex.hpp>
#include <boost/thread/condition.hpp>
使用动态库链接时，仅需要包含的lib为：
debug版：boost_system-vc80-mt-gd-1_55.lib，同时在生成的exe加入boost_system-vc80-mt-gd-1_55.dll
release版：boost_system-vc80-mt-1_55.lib，同时在生产的exe路径下加入boost_system-vc80-mt-1_55.dll
㈧ 动态库链接编译
这里的动态的意思应该是模块代码是动态加载的
而不是随着应用程序一起编译
只要动态库里的函数接口不变
应用程序就无需重新编译
只需将动态库重新编译后替换掉旧的动态库即可
如果动态库的函数接口有变动
那么应用程序就要重新编译发布
这也是我的个人理解~~~
㈨ 动态库 是什么
首先，想要知道动态库，我们得了解C++/C以及计算机的一些背景知识。
一般而言，在Windows下，*.dll文件就是动态库文件。用C++/C开发的程序，在发布的时候，会出现两种情况,第一，整个软件就只有一个文件，你只要双击那个exe文件，就可以运行。第二，除了exe之外，还有dll等文件。在这里，我们假设的文件只有exe文件和dll文件, 不讨论什么图标之类文件。
只有一个文件的，库已经嵌到那个exe里面。而有很多dll文件的程序，库没有嵌入到exe里面。所以，你可以看一下，如果那个exe文件大小非常大，那就说明是静态链接，在开发的时候是使用静态库。如果那个exe非常小，那么一般是使用的动态库。
那么问题来了，动态库与静态库相比优势又是什么。动态库节约内存，为什么这么说呢。假如两个类型的程序，如果他们都有一个共同使用的dll，那么在内存里面，只有一份，而不是两份。如果是使用了静态库，这会有两份，会有很大的浪费空间。
当然，使用动态库还有需要注意的地方。比如，有两个名字一模一样的动态库Qtcore4.dll，但是呢，一个dll是用vs2010编译器生成的，一个是用vs2015编译器生成的。如果，exe使用的dll弄错的话，程序结果会不对或者其他奇葩的问题。
以上均是一个大致的讲解，细节部分请参考程序员的自我修养这本书！
㈩ 动态库编译详解
当前类介绍:upper.c ( upper) 依赖于 bottom.c(play)
说明:当执行可执行程序的时候,需要去/lib. /user/lib下和LD_LIBRARY_PATH下寻找so.并不会在当前目录下寻找.
所以执行./main.out会报错.如下:
解决方案:指定.so运行搜寻路径
1.-Wl,-rpath ./mypath 加入参数,并且将libplay.so 到./mypath目录下.
2.设置LD_LIBRARY_PATH,指定目录.
说明:指定了-Wl,-rpath, 设置LD_LIBRARY_PATH也是可以生效的.并不是说只会去-Wl,-rpath下寻找.
首先生成一个bottom.so,然后用upper.so去依赖bottom.so, 然后main.c 再去依赖upper.so.
说明:这里编译的时候直接出错,是因为没有指定搜寻路径,所以无法通过编译.
解决编译问题方案.
1.我们依然采用LD_LIBRARY_PATH的方式可以解决编译和运行的问题.
2.生成libplay的时候,直接指定-Wl,-rpath 给libbottom.可以解决编译不通过的问题.
3.依赖所有库
依赖所有库只能解决编译问题,无法处理运行的路径.
另一种思路:我们在执行main.out的时候 执行-Wl,-rpath.并不在生成libplay的时候指定,看下是否正常.
由此可见,-Wl,-rpath 只能针对直接依赖的libplay.so指定了路径,但是libbottom还是无法查找到 .但是LD_LIBRARY是可以的.
rpath只能对直接依赖的so设置搜寻目录,并且可以设置所有依赖的编译路径.
总结: 解决编译问题,在生成libplay的时候指定-Wl,-rpath运行路径,或者设置LD_LIBRARAY_PATH,都可以解决这个问题.
当我们现在拥有的so包含一个直接依赖的so和很多间接依赖的so,但是没有设置rpath.所以是不能直接依赖主so进行编译和运行的.
为了通过编译:
1.在只链接主so的情况下可以去设置rpath或者LD_LIBRARY_PATH.
2.或者链接所有so.
为了通过运行:
为了正常运行可以设置LD_LIBRARY_PATH.
--disable-new-dtags,---dt-needed-entries
结论概述:
1.我们在生成间接依赖的库的时候,为了保证其他库可以直接依赖,需要加入-Wl,-rpath.保证编译通过.
2.LD_LIBRARY_PATH可以解决一切编译运行问题.