[[387528]]

我們隨便開發(fā)一個C/C++程序，都很大程度不可避免的需要用到動態(tài)庫：

// 來源：公眾號【編程珠璣】 
#include <stdio.h> 
int main() 
{ 
    printf("hello，編程珠璣\n"); 
    return 0; 
} 

編譯并查看使用到的動態(tài)庫：

$ gcc -o main main.c 
$ ldd main 
    linux-vdso.so.1 (0x00007ffdf8fdf000) 
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1f8535e000) 
    /lib64/ld-linux-x86-64.so.2 (0x00007f1f85951000) 

從ldd命令的結(jié)果我們可以看到main程序依賴了哪些動態(tài)庫，并且在哪個路徑。那么你有沒有想過，動態(tài)庫的路徑是怎么找到的，查找順序又是怎樣的呢?

準(zhǔn)備動態(tài)庫

在此之前如果你還沒有對動態(tài)庫有一個基本的了解的話，建議你閱讀《淺談靜態(tài)庫和動態(tài)庫》或其他相關(guān)資料。為了說明后面的問題，這里我們先創(chuàng)建一個簡單的動態(tài)庫，你也可以參考《手把手教你制作動態(tài)庫》：

// test.c 
//來源：公眾號【編程珠璣】 
#include <stdio.h> 
#include "test.h" 
#include "test1.h" 
void test() 
{ 
    printf("I am test；hello，編程珠璣\n"); 
    test1(); 
} 
 
// test.h 
void test(); 
 
 
//test1.c 
#include <stdio.h> 
#include "test1.h" 
void test1() 
{ 
    printf("test1,needed by test\n"); 
} 
// test1.h 
void test1(); 

分別制作動態(tài)庫libtest.so和libtest1.so，這在后面的示例中會用到：

$ gcc test1.c -fPIC -shared -o libtest1.so 
$ gcc test.c -fPIC -shared -o libtest.so -L. -ltest1 

這樣你在當(dāng)前目錄下就會看到有一個libtest.so和libtest1.so文件生成了，其中l(wèi)itest.so依賴libtest.so

注意，由于libtest.so依賴libtest1.so，這里用-L指定了要鏈接的test1的路徑，因此我們看到：

$ ldd libtest.so 
    linux-vdso.so.1 (0x00007ffd1bbca000) 
    libtest1.so => not found 
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9f1d0ae000) 
    /lib64/ld-linux-x86-64.so.2 (0x00007f9f1d6a1000) 

從這里可以看出libtest是依賴libtest1庫的，但是特別注意到，libtest1.so指向的是not found，這會有什么影響嗎?我們后面就會看到。

鏈接時查找路徑

我們都知道，在編譯成可執(zhí)行文件前，鏈接器鏈接動態(tài)庫也是需要查找動態(tài)庫路徑的，否則怎么鏈接上指定的動態(tài)庫呢?那么這個順序又是怎樣的呢?

首先會查找的會是編譯時鏈接的路徑。修改前面的main.c，讓它調(diào)用libtest.so中的test函數(shù)：

// 來源：公眾號【編程珠璣】 
#include <stdio.h> 
#include "test.h" 
int main() 
{ 
    test(); // 調(diào)用libtest.so中的test函數(shù) 
    return 0; 
} 

編譯鏈接：

$ gcc -o main main.c -I ./ -L./ -ltest -ltest1 

完美編譯過。除此之外，如果我們把libtest.so和libtest1.so都移到/usr/lib下面，我們發(fā)現(xiàn)，即便不用-L也能編譯過了:

$ gcc -o main main.c -I ./  -ltest -ltest1 

這里需要說明的是，我們通過-L./來指定搜索庫的路徑，由于libtest.so依賴libtest1.so，因此在編譯鏈接時，也需要鏈接上test1。

小結(jié)

從上面的內(nèi)容可以看到，在鏈接時，我們通過-L參數(shù)搜索要鏈接的庫路徑，但是這個路徑信息不會寫到ELF文件中，因此你會通過ldd命令看到not found，而通過-rpath可以指定鏈接時的搜索路徑，這個信息會寫入到ELF文件中，最終看到的結(jié)果是，由于libtest.so依賴libtest1.so，所以其他程序依賴libtest.so時，會自動從寫入ELF的rpath中搜索它依賴的其他庫，因此只需要鏈接libtest即可，例如：

在制作庫libtest1.so時，加上-rpath-link選項(xiàng)：

$ gcc test.c -fPIC -shared -o libtest.so -L. -ltest1 -Wl,-rpath-link $(pwd) 

在編譯main的時候，就不需要特意指定鏈接libtest1.so

$ gcc -o main main.c -L ./ -ltest 

只需要鏈接libtest.so，其依賴的libtest1.so也鏈接進(jìn)來了。

當(dāng)然了，如果-L指定的路徑?jīng)]有呢,它還會去查找其他地方，否則依賴的系統(tǒng)庫怎么找到呢?總結(jié)大致順序如下：

• -L指定鏈接路徑
• 對于依賴庫中依賴的搜索順序通過-rpath-link或-rpath選項(xiàng)查找(后面會提到)
• gcc默認(rèn)鏈接路徑(gcc --print-search-dir | grep libraries 查看)
• 鏈接器配置的查找路徑(ld -verbose | grep SEARCH_DIR查看)

針對具體的系統(tǒng)或鏈接器，可能有些差異，但是大致如此。

運(yùn)行時查找路徑

雖然前面編譯成功了，但是我們運(yùn)行看看，發(fā)現(xiàn)運(yùn)行失敗了。

$ ./main 
./main: error while loading shared libraries: libtest.so: cannot open shared object file: No such file or directory 

其實(shí)我們用ldd命令看一下也能看到：

linux-vdso.so.1 (0x00007ffcd566e000) 
    libtest.so => not found 
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f356d1f6000) 
    /lib64/ld-linux-x86-64.so.2 (0x00007f356d7e9000) 

LD_PRELOAD環(huán)境變量

這個環(huán)境變量在介紹《性能優(yōu)化-使用高效內(nèi)存分配器》中的時候，也有提到，用來做測試非常方便，同樣的，這種方式也最好僅僅只是用于測試，因?yàn)樗膬?yōu)先級非常高，并且影響全局。使用也很簡單：

$ export LD_PRELOAD=./libtest.so 
$ ./main 

為了避免影響后面的驗(yàn)證，這里取消設(shè)置該環(huán)境變量：

unset LD_PREALOD 

查找rpath路徑

上面的情況是找不到動態(tài)庫，那么它首先會去rpath指定路徑去查找，這需要在編譯時指定：

$ gcc test.c -fPIC -shared -o libtest.so -L. -ltest1 -Wl,-rpath $(pwd) 
$ gcc -o main main.c -L . -ltest -Wl,-rpath $(pwd) 
$ ./main 
I am test；hello，編程珠璣 
test1,needed by test 

也就是說，如果我們編譯時指定了路徑，就可以找到了，但是這些信息被寫入到了ELF文件中。

LD_LIBRARY_PATH環(huán)境變量

另外也可以通過這個環(huán)境變量來設(shè)置要搜索庫的路徑。

$ gcc -o main main.c -L . -ltest 
$ export LD_LIBRARY_PATH=./ 
$ ./main 

這樣運(yùn)行也是沒有問題的。

同樣，為了避免對后面測試產(chǎn)生影響，取消設(shè)置該環(huán)境變量：

unset LD_LIBRARY_PATH 

/etc/ld.so.conf中的路徑

我的機(jī)器上這個文件的內(nèi)容如下：

$ cat /etc/ld.so.conf 
include /etc/ld.so.conf.d/*.conf 
$ ls /etc/ld.so.conf.d/ 
fakeroot-x86_64-linux-gnu.conf  libc.conf  x86_64-linux-gnu.conf 

所以它實(shí)際指的是/etc/ld.so.conf.d/目錄下所有conf路徑包含路徑，打開其中一個libc.conf，它里面包含的路徑為：

$ /usr/local/lib 

既然如此，我們把前面的libtest.so復(fù)制到該目錄下(可能需要sudo權(quán)限)：

$ sudo cp libtest.so /usr/local/lib 
$ sudo ldconfig 
$ ./main 
I am test；hello，編程珠璣 
test1,needed by test 

注意，這里拷貝完成后，需要執(zhí)行l(wèi)dconfig，它會更新相應(yīng)的共享庫，以便可執(zhí)行程序能夠找到。實(shí)際上，執(zhí)行完成后，你確實(shí)就能在/etc/ld.so.cache文件中找到：

$ grep -a libtest.so /etc/ld.so.cache 

同樣，為了影響后面測試，記得刪除：

rm /usr/local/lib/libtest.so 

實(shí)際上這里是先從/etc/ld.so.cache中的路徑查找，然后再從ld.so.conf的路徑中查找。后面我們可以通過命令看到。

/usr/lib，/lib/

當(dāng)然了，如果以上路徑都沒有，最終還會在lib或/usr/lib下找，為了驗(yàn)證，我們將庫拷貝到/lib目錄下

$ cp libtest.so /lib 
$ ./main 
I am test；hello，編程珠璣 
test1,needed by test 

同樣能正常運(yùn)行。

小結(jié)

小結(jié)一下，動態(tài)庫的搜索順序如下：

• LD_PRELOAD環(huán)境變量指定庫路徑
• -rpath鏈接時指定路徑
• LD_LIBRARY_PATH環(huán)境變量設(shè)置路徑
• /etc/ld.so.conf配置文件指定路徑
• 默認(rèn)共享庫路徑，/usr/lib，lib

以上這些查找路徑你很容易來驗(yàn)證它們的優(yōu)先級，簡單的做法就是這幾個位置分別放置同名不同作用的庫，來看看它到底先使用哪個路徑下的庫，可自行嘗試。

LD_DEBUG

這個環(huán)境通常用來調(diào)試。例如，查看整個裝載過程：

$ LD_DEBUG=files ./main 

或者查看依賴的庫的查找過程：

$ LD_DEBUG=libs ./main 
      3557:    find library=libtest.so [0]; searching 
      3557:     search cache=/etc/ld.so.cache 
      3557:      trying file=/usr/local/lib/libtest.so 

另外還可以顯示符號的查找過程：

$ LD_DEBUG=symbols ./main 

總結(jié)

了解動態(tài)庫的搜索路徑，可以在開發(fā)中很好的幫助你定位找不到庫的問題，同時LD_DEBUG環(huán)境變量也能夠很好的幫助你調(diào)試，例如查看庫搜索的路徑，顯示符號的查找過程等等。

雖然程序運(yùn)行能夠有多種途徑獲取動態(tài)庫路徑，但是并不是每種方式都合適，有的方式甚至完全不該用，但這超出了本文的討論范圍了。有興趣的也可以點(diǎn)擊閱文原文，查看《Why LD_LIBRARY_PATH is bad》