程序在編譯時動態庫尋找目錄
① 電腦庫是什麼
所謂一個庫，就是一個文件，這個文件可以在編譯時由編譯器直接鏈接到可執行程序中，也可以在運行時由操作系統的runtime enviroment根據需要動態載入到內存中。一組庫，就形成了一個發布包，當然，具體發布多少個庫，完全由庫提供商自己決定。
所謂程序庫，一般是軟體作者為了發布方便、替換方便或二次開發目的，而發布的一組可以單獨與應用程序進行compile time或runtime鏈接的二進制可重定位目標碼文件。
所謂靜態庫，就是在靜態編譯時由編譯器到指定目錄尋找並且進行鏈接，一旦鏈接完成，最終的可執行程序中就包含了該庫文件中的所有有用信息，包括代碼段、數據段等。所謂動態庫，就是在應用程序運行時，由操作系統根據應用程序的請求，動態到指定目錄下尋找並裝載入內存中，同時需要進行地址重定向。 win32平台下，靜態庫通常後綴為.lib，動態庫為.dll linux平台下，靜態庫通常後綴為.a，動態庫為.so 從本質上來說，由同一段程序編譯出來的靜態庫和動態庫，在功能上是沒有區別的。不同之處僅僅在於其名字上，也就是「靜態」和「動態」。由上面的介紹不難看出，相對於動態庫，靜態庫的優點在於直接被鏈接進可執行程序中，之後，該可執行程序就不再依賴於運行環境的設置了（當然仍然會依賴於 CPU指令集和操作系統支持的可執行文件格式等硬性限制）。而動態庫的優點在於，用戶甚至可以在程序運行時隨時替換該動態庫，這就構成了動態插件系統的基礎。具體使用靜態庫和動態庫，由程序員根據需要自己決定。
② gcc 在編譯時如何去尋找所需要的頭文件
當我們給
$ gcc -o foo.o foo.c
gcc怎麼知道去哪裡找foo.c裡面所include的header文件,連結資料庫與系統定義呢? 總共有下列來源指定gcc去那找。
當初在編譯時指定的(在~gcc/gcc/collect2.c:locatelib()
寫在specs內的
後來用-D -I -L指定的
gcc環境變數設定(編譯的時候)
ld.so的環境變數(這是run time的時候)
在
prefix/lib/gcc-lib/xxxx-xxx-xxx-gnulibc/2.9.5/
裡面有個很重要的specs這個檔案 gcc根據這個檔，做一些內定的動作。 通常系統上的specs內定裝起來是在
/usr/lib/gcc-lib/xxxx-gnulibc/version/
specs檔看起來是像這樣
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
*asm_final:
%|
*cpp:
%(cpp_cpu) %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{posix:
-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
*cc1:
%(cc1_cpu) %{profile:-p}
*cc1plus:
*endfile:
%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s
*link:
-m elf_i386 %{shared:-shared} %{!shared: %{!ibcs: %{!static:
%{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker
/lib/ld-linux.so.2}} %{static:-static}}}
*lib:
%{shared: -lc --version-script libgcc.map%s} %{!shared: %{mieee-fp:-lieee}
%{pthread:-lpthread} %{profile:-lc_p} %{!profile: -lc}}
*libgcc:
-lgcc
*startfile:
%{!shared: %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} %{!p:%{profile:gcrt1.o%s}
%{!profile:crt1.o%s}}}} crti.o%s %{!shared:crtbegin.o%s}
%{shared:crtbeginS.o%s}
*switches_need_spaces:
*signed_char:
%{funsigned-char:-D__CHAR_UNSIGNED__}
*predefines:
-D__ELF__ -Dunix -Di386 -D__i386__ -Dlinux -Asystem(posix)
*cross_compile:
0
*version:
egcs-2.91.66
*multilib:
. ;
*multilib_defaults:
*multilib_extra:
*multilib_matches:
*linker:
collect2
*cpp_cpu_default:
-D__tune_i386__
*cpp_cpu:
-Asystem(unix) -Acpu(i386) -Amachine(i386) %{!ansi:-Di386}
-D__i386 -D__i386__ %{march=i486:-D__i486 -D__i486__}
%{march=pentium|march=i586:-D__pentium -D__pentium__ }
%{march=pentiumpro|march=i686:-D__pentiumpro -D__pentiumpro__ }
%{m386|mcpu=i386:-D__tune_i386__ } %{m486|mcpu=i486:-D__tune_i486__ }
%{mpentium|mcpu=pentium|mcpu=i586:-D__tune_pentium__ }
%{mpentiumpro|mcpu=pentiumpro|mcpu=i686:-D__tune_pentiumpro__ }
%{!mcpu*:%{!m386:%{!m486:%{!mpentium*:%(cpp_cpu_default)}}}}
*cc1_cpu:
%{!mcpu*: %{m386:-mcpu=i386} %{mno-486:-mcpu=i386 -march=i386}
%{m486:-mcpu=i486} %{mno-386:-mcpu=i486 -march=i486}
%{mno-pentium:-mcpu=i486 -march=i486} %{mpentium:-mcpu=pentium}
%{mno-pentiumpro:-mcpu=pentium} %{mpentiumpro:-mcpu=pentiumpro}}
在shell下用這行，-E 表示只做到preprocess就好
$ echo 'main(){}' | gcc -E -v -
你會看到gcc去讀specs檔
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
gcc version 2.95.2 20000220 (Debian GNU/Linux)
/usr/lib/gcc-lib/i386-linux/2.95.2/cpp -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -
GNU CPP version 2.95.2 20000220 (Debian GNU/Linux) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc-lib/i386-linux/2.95.2/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/lib/gcc-lib/i386-linux/2.95.2/../../../../include/g++-3
/usr/lib/gcc-lib/i386-linux/2.95.2/../../../../i386-linux/include
End of omitted list.
# 1 ""
main(){}
所以有內定的定義，(就是用在#if defined #ifndef #define這些東西， 如果有定義這個字元串，就去編譯等等。) -Dxxxx -Dxxxx -Axxxx。 還有內定的include文件的搜尋路徑
/usr/include
/usr/local/include
/usr/lib/gcc-lib/i386-linux/2.95.2/include
/usr/lib/gcc-lib/i386-linux/2.95.2/../../../../include/g++-3
/usr/lib/gcc-lib/i386-linux/2.95.2/../../../../i386-linux/include
但是如果裝gcc的時候，是有給定的prefix的話，那麼就是
/usr/include
prefix/include
prefix/xxx-xxx-xxx-gnulibc/include
prefix/lib/gcc-lib/xxxx-xxx-xxx-gnulibc/2.8.1/include
所以header file的搜尋會從-I開始然後找gcc的環境變數 C_INCLUDE_PATH,CPLUS_INCLUDE_PATH,OBJC_INCLUDE_PATH 再找上述的內定目錄
函式庫
當我們用到數學函式cos()，cos這個symbol，gcc並不曉它到底是什麼東西， 是變數，是函式，要預留多少空間給他等等，完全沒有任何訊息，你必須標頭 檔要#include ，gcc才知道。而且因為specs這個檔裡面只有要 link -lc也就是只有libc.so這個檔內的symbol會被搜尋， 像printf scanf等都在這裡面，可是像cos()等就沒有了， 所以函式庫的選項要多加 -lm ，這時ld才會來找libm這個函式庫，
編譯的時候，gcc會去找-L，再找gcc的環境變數LIBRARY_PATH，再找內定目錄 /lib /usr/lib /usr/local/lib 這是當初compile gcc時寫在程序內的， gcc環境變數與pass給ld的機制在~gcc/gcc/collect2.c下找得到。 這上面只是搜尋路徑而已，如果要不加-lm 也能正確的主動搜尋某個特定的lib，例如libm， 就要去在specs這個檔案改一下，把math這個函式庫加進自動聯結函式庫 之一。就不用寫-lm了。
RUN TIME的時候， 如果編譯時沒有指定-static這個選項，其實可執行文件並不是真的可執行， 它必須在執行(run time)時需要ld.so來做最後的連結動作，建造一個可執行的 image丟到內存。如果是靜態連結，編譯時ld會去找libm.a的檔 。如果是動態連結去找libm.so。 所以每次有新改版程序， 或新加動態函式庫如果不在原本的/etc/ld.so.conf搜尋路徑中，都要把路徑 加進來，然後用
ldconfig -v
會重建cache並且顯示它所參照的函式庫。Run Time時ld.so才找得到lib"執行"。 ld與ld.so不一樣喔。
一些重要的程序
ld :Link Editor 連結各obj寫進一個可執行檔(executable)。
ldd :秀出一個執行文件用了那些動態函式庫。
ld.so :Dynamic Linker, 動態連結的話，是由ld.so完成執行時期symbol的
:參照與連結。
ld-linux.so :ELF文件的動態連結，跟ld.so一樣。只是ld.so是給a.out format的。
:新的glicb2的ld-linux.so.2已經跟ld.so.2結合成單一程序了。
ldconfig :根據/etc/ld.so.conf內的目錄，做出動態連結所需的cache檔。
ld 就是負責各個函式庫文件的信息寫進最後可執行檔(executable)，所以它叫做 link editor，編譯時根據flags -L搜尋需要的lib，gcc也會把他的設定pass下來。 ld.so ld-linux.so.2是負責最後動態連結，叫做dynamic linker， RUN Time 執行程序時,它根據這個順序搜尋函式庫。
LD_LIBRARY_PATH 或LD_AOUT_LIBRARY_PATH環境變數所指的路徑
ldconfig所建立的cache
/lib /usr/lib內的檔
來找程序所需要的動態函式庫
ldconfig會根據/etc/ld.so.conf這個檔的設定，加上內定的兩個目錄 /lib /usr/lib來設定ld.so要用到所需要的連結 以及連結的cache到/etc/ld.so.cache。 所以如果換了新的函式庫，新的kernel，內部的標頭檔可能會有變化， 都要跟著改變讓gcc正確的找到，喔不，應該是cpp, ld, ld.so能正確的找到。 不然編出來的執行檔可能是錯誤的，執行時還可能segmentation fault。
③ ndk-Android NDk 怎麼編譯時動態鏈接第三方so庫，有頭文件
問題描述：Android如何調用第三方SO庫；
已知條件：SO庫為Android版本連接庫（*.so文件），並提供了詳細的介面說明；
已了解解決方案：
1.將SO文件直接放到libs/armeabi下，然後代碼中System.loadLibrary("xxx")；再public native static int xxx_xxx_xxx()；接下來就可以直接調用xxx_xxx_xxx()方法；
2.第二種方案，創建自己的SO文件，在自己的SO文件里調用第三方SO，再在程序中調用自己的SO，這種比較復雜，需要建java類文件，生成.h文件，編寫C源文件include之前生成的.h文件並實現相應方法，最後用android NDK開發包中的ndk-build腳本生成對應的.so共享庫；
求解：
1.上面兩種方案是否可行？不可行的話存在什麼問題？
2.兩種方案有什麼區別？為什麼網上大部都是用的第二種方案？
3.只有一個*.so文件，並提供了詳細的介面說明，是否可在ANDROID中使用它？
首先要看這個SO是不是JNI規范的SO，比如有沒有返回JNI不直接支持的類型。也就是說這個SO是不是可以直接當作JNI來調用。如果答案是否定的，你只能選第二個方案。
如果答案是肯定的，還要看你是不是希望這個SO的庫直接暴露給JAVA層，如果答案是否定的，你只能選第二個方案，比如你本身也是一個庫的提供者。
一般如果你只有SO，就說明這個是別人提供給你的，你可以要求對方給你提供配套的JAVA調用文件。
1、這個要看這個SO是不是符合JNI調用的規范。還要看你自己的意願。
2、因為第二種方法最靈活，各種情況都可以實現。
3、可以
看能不能直接從JAVA調用的最簡單的方法就是看SO里的函數名是不是Java_XXX_XXX_XXX格式的
是就可以，你可以自己寫一個配套的JAVA文件，注意一下SO函數名和JAVA函數名的轉換規則，或者向SO提供方索要；
不是的話就選第二種方案吧。
1、檢查所需文件是否齊全
使用第三方動態庫，應該至少有2個文件，一個是動態庫（.so），另一個是包含
動態庫API聲明的頭文件(.h)
2、封裝原動態庫
原動態庫文件不包含jni介面需要的信息，所以我們需要對其進行封裝，所以我
們的需求是：將libadd.so 裡面的API封裝成帶jni介面的動態
3、編寫庫的封裝函數libaddjni.c
根據前面生成的com_android_libjni_LibJavaHeader.h 文件，編寫libaddjni.c，用
來生成libaddjni.so
Android中集成第三方軟體包（.jar, .so）
Android中可能會用到第三方的軟體包，這包括Java包.jar和Native包.so。jar包既可通過Eclipse開發環境集成，也可通過編譯源碼集成，看你的工作環境。
假定自己開發的程序為MyMaps，需要用到BaiMaps的庫，包括mapapi.jar和libBMapApiEngine_v1_3_1.so。
一、Eclipse中集成第三方jar包及.so動態庫
MyMaps工程下創建目錄libs以及libs/armeabi，把mapapi.jar放在的libs/目錄下，把libBMapApiEngine_v1_3_1.so放在libs/armeabi/下。
Eclipse中把第三方jar包mapapi.jar打包到MyMaps的步驟：
1. 右擊工程，選擇Properties；
2. Java Build Path，選擇Libraries；
3. Libraries頁面點擊右面按鈕「Add Library…」；
4. 選擇「User Library」，點擊「Next」；
5. 點擊「User Libraries」按鈕；
6. 在彈出界面中，點擊「New…」；
7. 輸入「User library name」，點擊「OK」確認；
8. 返回之後，選擇剛剛創建的User library，右面點擊「AddJARs」；
9. 選擇MyMaps/libs/下的mapapi.jar；
10. 確認，返回。
這樣，編譯之後，該jar包就會被打進MyMaps.apk中，libBMapApiEngine_v1_3_1.so也被打包在lib/armeabi/中。
程序運行過程中，libBMapApiEngine_v1_3_1.so被放在/data/data/<yourAppPackage>/lib/下，載入動態庫時系統會從程序的該lib/目錄下查找.so庫。
二、源碼中集成第三方集成jar包及.so動態庫
Android源碼中MyMaps放在packages/apps下。MyMaps下創建目錄libs以及libs/armeabi，並把mapapi.jar放在libs/，把libBMapApiEngine_v1_3_1.so放在libs/armeabi。
2.1 修改Android.mk文件
Android.mk文件如下：
[plain] view plain
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := optional
LOCAL_STATIC_JAVA_LIBRARIES := libmapapi
LOCAL_SRC_FILES := $(call all-subdir-java-files)
LOCAL_PACKAGE_NAME := MyMaps
include $(BUILD_PACKAGE)
##################################################
include $(CLEAR_VARS)
LOCAL_PREBUILT_STATIC_JAVA_LIBRARIES :=libmapapi:libs/mapapi.jar
LOCAL_PREBUILT_LIBS :=libBMapApiEngine_v1_3_1:libs/armeabi/libBMapApiEngine_v1_3_1.so
LOCAL_MODULE_TAGS := optional
include $(BUILD_MULTI_PREBUILT)
# Use the following include to make our testapk.
include $(callall-makefiles-under,$(LOCAL_PATH))
1 集成jar包
LOCAL_STATIC_JAVA_LIBRARIES取jar庫的別名，可以任意取值；
LOCAL_PREBUILT_STATIC_JAVA_LIBRARIES指定prebuiltjar庫的規則，格式：別名:jar文件路徑。注意：別名一定要與LOCAL_STATIC_JAVA_LIBRARIES里所取的別名一致，且不含.jar；jar文件路徑一定要是真實的存放第三方jar包的路徑。
編譯用BUILD_MULTI_PREBUILT。
2 集成.so動態庫
LOCAL_PREBUILT_LIBS指定prebuilt so的規則，格式：別名:so文件路徑。注意：別名一般不可改變，特別是第三方jar包使用.so庫的情況，且不含.so；so文件路徑一定要是真實的存放第三方so文件的路徑。
編譯拷貝用BUILD_MULTI_PREBUILT。
2.2 加入到GRANDFATHERED_USER_MODULES
在文件user_tags.mk中，把libBMapApiEngine_v1_3_1加入到GRANDFATHERED_USER_MODULES中
[plain] view plain
GRANDFATHERED_USER_MODULES += \
… \
libBMapApiEngine_v1_3_1
user_tags.mk可以是build/core下的，也可以是$(TARGET_DEVICE_DIR)下的，推薦修改$(TARGET_DEVICE_DIR)下的。
2.3 編譯結果
MyMaps.apk編譯生成在out/target/proct/<YourProct>/system/app/下；
libBMapApiEngine_v1_3_1.so放在out/target/proct/<YourProct>/system/lib/下，這也是系統載入動態庫時搜索的路徑。
④ 如何載入動態庫dll
可以通過兩種方式
1.隱式鏈接(需要.dll,.lib,.h)
2.顯式鏈接(需要.dll,.h)
方法1：隱式鏈接----需要.lib，.dll，.h文件
隱式鏈接就是在程序開始執行時就將DLL文件載入到內存當中，而顯示鏈接，是實時載入，程序需要的時候載入，不需要的時候，卸載。
這種方式需要DLL文件,以及相應的Lib文件和頭文件。
只要沒有在程序中顯式鏈接的，都是隱式鏈接
Windows程序bin目錄包含了可執行文件(.exe)和動態鏈接庫(.dlll),lib目錄包含了靜態庫。
步驟
第一步：將.dll,lib,.h文件放入對應的搜索路徑
●其中動態庫的搜索路徑點擊這里查看，記住最重要的兩個
1、項目當前目錄(.cpp)目錄
2、path環境變數中的目錄
●靜態庫的搜索路徑包括
1、項目當前目錄.cpp目錄(項目和解決方案的Debug不行)(也不是解決方案目錄)
2、VC設置中的庫目錄(Library Directories)
所以採用隱式鏈接方式的時候，只載入需要的DLL，在附加依賴項中，只添加需要的DLL對於的lib,不要多加，否則會造成1.加大程序啟動時間 2.內存浪費
⑤ VC中編程，既然在Setting中設置了鏈接dll，為什麼還要把dll拷貝到程序所在的目錄中哪
dll是動態鏈接庫，不會跟隨工程一起編譯，所以你的程序如果要調用動態庫的函數，必須先載入動態庫進你內存，然後取得函數地址才能開始調用函數，雖然這些是編譯器自動幫你加入了這些載入和取函數的過程，但編譯器無法確定你的動態庫在運行環境的什麼地方，因為你的程序可能運行在你編譯的機器，也可能運行在別人的機器上，而且很難保證你會不會為這個動態庫做安裝程序，比如一些固有的系統動態庫函數，就沒必要跟著安裝程序一起走，所以你的程序會先從系統目錄開始找是否存在你的動態庫文件，如果沒有就會到你程序的當前目錄尋找你的動態庫文件，如果都沒發現，程序就會出錯了。所以，通常這種動態庫文件不是放到系統目錄就是放到安裝目錄就是這個原因。但如果你用的是靜態庫，那麼就和動態庫不一樣了，靜態庫可跟隨你的工程一起編譯，所以編譯完了之後就無需在拖帶靜態庫文件一起運行，如果你在全無動態庫的情況下編譯程序，那麼就一個可執行文件便可隨處運行了，這種也叫綠色軟體，無需安裝便可使用。
⑥ 關於動態庫 靜態庫 區別與使用 路徑查找等
一、引言
我們通常把一些公用函數製作成函數庫，供其它程序使用。
函數庫分為靜態庫和動態庫兩種。
通常情況下，對函數庫的鏈接是放在編譯時期（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大小，運行的速度等綜合考慮。
⑦ 靜態庫和動態庫的區別
你好，卻別如下：
我們通常把一些公用函數製作成函數庫，供其它程序使用。
函數庫分為靜態庫和動態庫兩種。
靜態庫在程序編譯時會被連接到目標代碼中，程序運行時將不再需要該靜態庫。
動態庫在程序編譯時並不會被連接到目標代碼中，而是在程序運行是才被載入，因此在程序運行時還需要動態庫存在。
本文主要通過舉例來說明在Linux中如何創建靜態庫和動態庫，以及使用它們。
在創建函數庫前，我們先來准備舉例用的源程序，並將函數庫的源程序編譯成.o文件。
第1步：編輯得到舉例的程序--hello.h、hello.c和main.c;
hello.h(見程序1)為該函數庫的頭文件。
hello.c(見程序2)是函數庫的源程序，其中包含公用函數hello，該函數將在屏幕上輸出"Hello XXX!"。
main.c(見程序3)為測試庫文件的主程序，在主程序中調用了公用函數hello。
程序1: hello.h
#ifndef HELLO_H
#define HELLO_H
void hello(const char *name);
#endif //HELLO_H
程序2: hello.c
#include
void hello(const char *name)
{
printf("Hello %s!/n", name);
}
程序3: main.c
#include "hello.h"
int main()
{
hello("everyone");
return 0;
}
第2步：將hello.c編譯成.o文件;
無論靜態庫，還是動態庫，都是由.o文件創建的。因此，我們必須將源程序hello.c通過gcc先編譯成.o文件。
在系統提示符下鍵入以下命令得到hello.o文件。
# gcc -c hello.c
#
(注1：本文不介紹各命令使用和其參數功能，若希望詳細了解它們，請參考其他文檔。)
(注2：首字元"#"是系統提示符，不需要鍵入，下文相同。)
我們運行ls命令看看是否生存了hello.o文件。
# ls
hello.c hello.h hello.o main.c
#
(注3：首字元不是"#"為系統運行結果，下文相同。)
在ls命令結果中，我們看到了hello.o文件，本步操作完成。
下面我們先來看看如何創建靜態庫，以及使用它。
第3步：由.o文件創建靜態庫;
靜態庫文件名的命名規范是以lib為前綴，緊接著跟靜態庫名，擴展名為.a。例如：我們將創建的靜態庫名為myhello，則靜態庫文件名就是libmyhello.a。在創建和使用靜態庫時，需要注意這點。創建靜態庫用ar命令。
在系統提示符下鍵入以下命令將創建靜態庫文件libmyhello.a。
# ar cr libmyhello.a hello.o
#
我們同樣運行ls命令查看結果：
# ls
hello.c hello.h hello.o libmyhello.a main.c
#
ls命令結果中有libmyhello.a。
第4步：在程序中使用靜態庫;
靜態庫製作完了，如何使用它內部的函數呢？只需要在使用到這些公用函數的源程序中包含這些公用函數的原型聲明，然後在用gcc命令生成目標文件時指明靜態庫名，gcc將會從靜態庫中將公用函數連接到目標文件中。注意，gcc會在靜態庫名前加上前綴lib，然後追加擴展名.a得到的靜態庫文件名來查找靜態庫文件。
在程序3:main.c中，我們包含了靜態庫的頭文件hello.h，然後在主程序main中直接調用公用函數hello。下面先生成目標程序hello，然後運行hello程序看看結果如何。
# gcc -o hello main.c -L. -lmyhello
# ./hello
Hello everyone!
#
我們刪除靜態庫文件試試公用函數hello是否真的連接到目標文件 hello中了。
# rm libmyhello.a
rm: remove regular file `libmyhello.a'? y
# ./hello
Hello everyone!
#
程序照常運行，靜態庫中的公用函數已經連接到目標文件中了。
我們繼續看看如何在Linux中創建動態庫。我們還是從.o文件開始。
第5步：由.o文件創建動態庫文件;
動態庫文件名命名規范和靜態庫文件名命名規范類似，也是在動態庫名增加前綴lib，但其文件擴展名為.so。例如：我們將創建的動態庫名為myhello，則動態庫文件名就是libmyhello.so。用gcc來創建動態庫。
在系統提示符下鍵入以下命令得到動態庫文件libmyhello.so。
# gcc -shared -fPCI -o libmyhello.so hello.o
#
我們照樣使用ls命令看看動態庫文件是否生成。
# ls
hello.c hello.h hello.o libmyhello.so main.c
#
第6步：在程序中使用動態庫;
在程序中使用動態庫和使用靜態庫完全一樣，也是在使用到這些公用函數的源程序中包含這些公用函數的原型聲明，然後在用gcc命令生成目標文件時指明動態庫名進行編譯。我們先運行gcc命令生成目標文件，再運行它看看結果。
# gcc -o hello main.c -L. -lmyhello
# ./hello
./hello: error while loading shared libraries: libmyhello.so: cannot open shared object file: No such file or directory
#
哦!出錯了。快看看錯誤提示，原來是找不到動態庫文件libmyhello.so。程序在運行時，會在/usr/lib和/lib等目錄中查找需要的動態庫文件。若找到，則載入動態庫，否則將提示類似上述錯誤而終止程序運行。我們將文件 libmyhello.so復制到目錄/usr/lib中，再試試。
# mv libmyhello.so /usr/lib
# ./hello
Hello everyone!
#
成功了。這也進一步說明了動態庫在程序運行時是需要的。
我們回過頭看看，發現使用靜態庫和使用動態庫編譯成目標程序使用的gcc命令完全一樣，那當靜態庫和動態庫同名時，gcc命令會使用哪個庫文件呢？抱著對問題必究到底的心情，來試試看。
先刪除 除.c和.h外的 所有文件，恢復成我們剛剛編輯完舉常式序狀態。
# rm -f hello hello.o /usr/lib/libmyhello.so
# ls
hello.c hello.h main.c
#
在來創建靜態庫文件libmyhello.a和動態庫文件libmyhello.so。
# gcc -c hello.c
# ar cr libmyhello.a hello.o
# gcc -shared -fPCI -o libmyhello.so hello.o
# ls
hello.c hello.h hello.o libmyhello.a libmyhello.so main.c
#
通過上述最後一條ls命令，可以發現靜態庫文件libmyhello.a和動態庫文件libmyhello.so都已經生成，並都在當前目錄中。然後，我們運行gcc命令來使用函數庫myhello生成目標文件hello，並運行程序 hello。
# gcc -o hello main.c -L. -lmyhello
# ./hello
./hello: error while loading shared libraries: libmyhello.so: cannot open shared object file: No such file or directory
#
從程序hello運行的結果中很容易知道，當靜態庫和動態庫同名時， gcc命令將優先使用動態庫。