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可以解決一切編譯運行問題.