動態庫依賴編譯鏈接

『壹』 動態庫編譯詳解

當前類介紹: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可以解決一切編譯運行問題.

『貳』 求助，依賴的動態庫包含靜態庫，編譯報錯說找

動態鏈接庫和靜態鏈接庫一般是編譯集成一系列的介面（函數）
在程序源代碼編譯完成後通過編譯器編譯並通過鏈接器與這些庫進行鏈接
動態鏈接庫與靜態鏈接庫的區別在於鏈接器在進行鏈接時靜態庫會被直接編譯進程序里
而動態鏈接庫並不會，我們這里將這些鏈接庫稱作依賴（動態庫和靜態庫）
程序的運行需要這些依賴，程序在靜態鏈接後該程序本身便已包含該依賴
而動態鏈接後的程序本身本不包含該依賴，這些依賴需要執行者自行安裝進操作系統（動態庫、運行時庫）
程序運行時會動態地載入這些庫

linux上動態庫一般的後綴後為.so
靜態庫一般的後綴為.a
由於靜態鏈接會直接將庫編譯進程序里所以靜態編譯後的程序相較於動態鏈接所要大
這就是因為靜態鏈接會將鏈接庫編譯進程序里的原因，所以佔用就要大了
出於這種原因，靜態庫不易於維護與更新，如果鏈接庫中有實現有bug等需要更新則需要更新整個程序，因為靜態庫被編譯進程序中了
但動態庫就沒有這種情況了，因為動態庫是程序運行時動態載入的，所以我們只需要更新動態庫而不需要更新所有依賴該庫的程序（軟體）

另一方面，很多程序的開發都會使用到相同的鏈接庫，也就是很多程序（軟體）會有相同的依賴
如果將這些依賴全部靜態編譯的話將會造成存儲資源佔用過多而造成資源浪費
而使用動態庫的方式這些程序（軟體）則可以共享一個鏈接庫，而不需要每個程序都帶一個鏈接庫，這樣就大大地減少了存儲資源佔用空間

『叄』 Linux下fortran編譯鏈接

so文件是動態庫的集合，由f90文件編譯而成，此時f90程序中一般不包含program開頭的主程序，而只包含mole，例如：

將f90源文件編譯為動態庫時，使用命令

此時將生成兩個文件，分別為bisectmod.mod和lib***.so，這兒的***是剛才自定義的名字，而*.mod文件名則是f90文件中mole的名字，是自動生成的，如果一個f90文件中包含N個mole，則會生成N個*.mod和1個lib***.so。so文件作為庫文件，也可以由多個f90文件共同編譯得到，相當於靜態庫中的打包，將多個庫打包到一個里，如下：

動態庫的使用包含兩部分，一是在編譯時，二是在程序運行時。
編譯包含動態庫的主程序時，要同時制定mod文件的路徑和so文件的路徑，如果mod文件、so文件以及主程序文件在同一目錄下，直接指定so文件即可：

但是當使用第三方庫時，通常會分別存放在include和lib文件夾中，此時就要單獨指定路徑了：

第一個參數-I是大寫的i，代表include，第二個l是小寫的L，代表lib的名字，可以省略lib以及後面的.so，第三個-L則是lib.so文件的路徑。

這樣編譯的結果不能運行，因為運行時程序找不到lib***.so文件，最好的辦法是指定LD_LIBRARY_PATH環境變數，當然也可以將lib***.so文件復制到系統的lib文件夾中。

『肆』 C語言編輯編譯連接的作用是什麼

C語言編輯的作用是檢查語法，製作C語言的源文件和頭文件，生成匯編代碼。

C語言編輯的作用是將匯編代碼轉換機器碼。在這一步中，會對文件內部的語法語義做處理，如果編譯出錯，無法進行後續動作。

C語言鏈接的作用是將機器碼鏈接到一起生成可執行程序。這一步會對文件之間的關聯做檢查，如果出錯，將不會生成可執行程序，也就無法執行。

(4)動態庫依賴編譯鏈接擴展閱讀：

C語言鏈接時，將源文件中用到的庫函數與匯編生成的目標文件.o合並生成可執行文件。該可執行文件會變大很多，一般是調用自己電腦上的靜態庫。

靜態庫和應用程序編譯在一起，在任何情況下都能運行，而動態庫是動態鏈接，文件生效時才會調用。很多代碼編譯通過，鏈接失敗就極有可能在靜態庫和動態庫這出現了紕漏，要視情況解決。缺少相關所需文件，就會鏈接報錯。這個時候就要檢查下本地的鏈接庫是不是缺損。

『伍』 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/下，這也是系統載入動態庫時搜索的路徑。

『陸』 g++ 編譯命令中依賴的動態庫如果還依賴別的庫，命令怎麼設置

第一步，我先從簡單的調用出發，定義了一個簡單的函數，該函數僅僅實現一個整數加法求和：

LIBEXPORT_API int mySum(int a,int b){ return a+b;}
C# 導入定義：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Auto,CallingConvention=CallingConvention.StdCall)]
public static extern int mySum (int a,int b);
}
在C#中調用測試：

int iSum = RefComm.mySum(,);

運行查看結果iSum為5，調用正確。第一步試驗完成，說明在C#中能夠調用自定義的動態鏈接庫函數。

第二步，我定義了字元串操作的函數（簡單起見，還是採用前面的函數名），返回結果為字元串：

LIBEXPORT_API char *mySum(char *a,char *b){sprintf(b,"%s",a); return a;}
C# 導入定義：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Auto,
CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, string b);
}
在C#中調用測試：

string strDest="";
string strTmp= RefComm.mySum("45", strDest);

運行查看結果 strTmp 為"45"，但是strDest為空。我修改動態鏈接庫實現，返回結果為串b：

LIBEXPORT_API char *mySum(char *a,char *b){sprintf(b,"%s",a) return b;}
修改 C# 導入定義，將串b修改為ref方式：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Auto,CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, ref string b);
}
在C#中再調用測試：

string strDest="";
string strTmp= RefComm.mySum("45", ref strDest);
運行查看結果 strTmp 和 strDest 均不對，含不可見字元。再修改 C# 導入定義，將CharSet從Auto修改為Ansi：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Ansi,CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, string b);
}
在C#中再調用測試：

string strDest="";
string strTmp= RefComm. mySum("45", ref strDest);
運行查看結果 strTmp 為"45"，但是串 strDest 沒有賦值。第二步實現函數返回串，但是在函數出口參數中沒能進行輸出。再次修改 C# 導入定義，將串b修改為引用（ref）：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Ansi,CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, ref string b);
}

運行時調用失敗，不能繼續執行。

第三步，修改動態鏈接庫實現，將b修改為雙重指針：

LIBEXPORT_API char *mySum(char *a,char **b){sprintf((*b),"%s",a); return *b;}
C#導入定義：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Ansi,CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, ref string b);
}
在C#中調用測試：

string strDest="";
string strTmp= RefComm. mySum("45", ref strDest);

運行查看結果 strTmp 和 strDest 均為"45"，調用正確。第三步實現了函數出口參數正確輸出結果。

第四步，修改動態鏈接庫實現，實現整數參數的輸出：

LIBEXPORT_API int mySum(int a,int b,int *c){ *c=a+b; return *c;}
C#導入的定義：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Ansi,CallingConvention=CallingConvention.StdCall)]
public static extern int mySum (int a, int b,ref int c);
}
在C#中調用測試：

int c=0;
int iSum= RefComm. mySum(,, ref c);

運行查看結果iSum 和c均為5，調用正確。

經過以上幾個步驟的試驗，基本掌握了如何定義動態庫函數以及如何在 C# 定義導入，有此基礎，很快我實現了變長加密函數在 C# 中的調用，至此目標實現。

三、結論

在 C# 中調用 C++ 編寫的動態鏈接庫函數，如果需要出口參數輸出，則需要使用指針，對於字元串，則需要使用雙重指針，對於 C# 的導入定義，則需要使用引用（ref）定義。

對於函數返回值，C# 導入定義和 C++ 動態庫函數聲明定義需要保持一致，否則會出現函數調用失敗。定義導入時，一定注意 CharSet 和 CallingConvention 參數，否則導致調用失敗或結果異常。運行時，動態鏈接庫放在 C# 程序的目錄下即可，我這里是一個 C# 的動態鏈接庫，兩個動態鏈接庫就在同一個目錄下運行。

『柒』 面試 | Linux 下的動態鏈接庫問題

在 Linux 開發時，我們經常會看到一些形如 xxx.so 的名稱出現，其中 so 是 Shared Object 的縮寫，即可以共享的目標文件，也就是我們所稱為的動態鏈接庫，和在 Windows 下大家玩 游戲 時遇到的 xxx.dll 錯誤中的文件是一個類型的。

面試中經常會問到以下問題：

庫是寫好的現有的，成熟的，可以復用的代碼。現實中每個程序都要依賴很多基礎的底層庫，不可能每個人的代碼都從零開始，因此庫的存在意義非同尋常。本質上來說庫是一種可執行代碼的二進制形式，可以被操作系統載入內存執行。

庫有兩種：

在一個程序的編譯過程中，分為以下幾個步驟： 預處理 ， 編譯 ， 匯編 ， 鏈接 。本文中討論的鏈接庫就是針對最後一個步驟「鏈接」而言的。

動態庫和靜態庫的區別

左圖為靜態鏈接庫，右圖為動態鏈接庫

對於靜態鏈接庫而言在鏈接階段，會將匯編生成的「目標文件.o」與引用到的庫一起鏈接打包到可執行文件中。因此對應的鏈接方式稱為靜態鏈接：

靜態鏈接可以理解為最後生成了一個「單文件免安裝綠色版」的程序，優點在於移植的時候只需要移動這一個文件，缺點在於文件體積非常大，為了解決這樣的問題，就有了動態鏈接庫。動態鏈接庫在程序編譯時並不會被連接到目標代碼中，而是在程序運行時才被載入。

動態庫連接到系統空間，如果多個程序連接了同一個庫，那麼只需要一份，優點在於編譯程序的時候不會將對應的庫文件全部打包在生成的程序中，而是保留了到對應庫的鏈接，缺點就是移植的時候如果只移動了對應的程序沒有安裝相關的庫的話，就會看到類似以下喜聞樂見的結果了。

在 Linux 下一個動態庫有y三個不同名字的文件組成：

當程序在內部列出所需要的鏈接庫時，僅僅使用 soname。當你創建一個鏈接庫時，使用 real name。安裝一個新的鏈接庫時，把它復制到一個DLL文件夾里，然後運行程序 ldconfig。ldconfig 檢查存在的 real name 文件，並且創建指向它符號鏈接 soname 文件。可能大家比較常見到的有 libsodium 等。

有了上面關於庫的一些基礎知識之後，我們可以開始嘗試創建一個動態庫來供程序使用了。

比如我們有一個求最大值的函數 max(int a,int b,int c) ，放在文件 max.c 中文件內容如下：

可以通過：

將其編譯為共享庫，-fPIC是編譯選項，PIC是 Position Independent Code 的縮寫，表示要生成位置無關的代碼，這是動態庫需要的特性； -shared是鏈接選項，告訴 gcc 生成動態庫而不是可執行文件。為了讓用戶知道我們的動態庫中有哪些介面可用，我們需要編寫對應的頭文件，比如可以寫一個 max.h ：

設置一個驅動函數來測試我們編寫的動態庫：

通過 gcc test.c -L. -lmax來生成 a.out，其中-lmax表示要鏈接 libmax.so，-L.表示搜索要鏈接的庫文件時包含當前路徑。

但是這樣直接運行的話，會出現一個錯誤：

由於 Linux 是通過/etc/ld.so.cache文件搜尋要鏈接的動態庫的，而 /etc/ld.so.cache 是 ldconfig 程序讀取 /etc/ld.so.conf 文件生成的，本次使用的動態庫 libmax.so 並不在對應的目錄下，就會導致程序無法找到對應的動態鏈接庫，這樣我們的解決方法有二：

小結

​動態鏈接庫是各個系統中的一個重要的組成部分且在 Linux 開發相關領域中尤為重要，也是一個面試的高頻考點，除了動態鏈接庫以外，還有以下相關知識也是高頻考點，在面試前一定要准備好：

本文作者：Nova Kwok

『捌』 Linux動態庫多重依賴，編譯問題！！！！！！

這只能說明一個問題，你依賴的庫本隱基銷身有問題，沒有把它的依鋒檔賴都加進去，也就是你例子中的①灶游libb.so依賴liba.so;，你應該在生成libb.so的時候，把對liba.so的依賴加進去，這樣應該就沒有問題了。