程序運行時，是怎么找到動態庫的？
我們隨便開發一個C/C++程序，都很大程度不可避免的需要用到動態庫：
- // 來源：公眾號【編程珠璣】
- #include <stdio.h>
- int main()
- {
- printf("hello，編程珠璣\n");
- return 0;
- }
編譯并查看使用到的動態庫：
- $ 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命令的結果我們可以看到main程序依賴了哪些動態庫，并且在哪個路徑。那么你有沒有想過，動態庫的路徑是怎么找到的，查找順序又是怎樣的呢?
準備動態庫
在此之前如果你還沒有對動態庫有一個基本的了解的話，建議你閱讀《淺談靜態庫和動態庫》或其他相關資料。為了說明后面的問題，這里我們先創建一個簡單的動態庫，你也可以參考《手把手教你制作動態庫》：
- // 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();
分別制作動態庫libtest.so和libtest1.so，這在后面的示例中會用到：
- $ gcc test1.c -fPIC -shared -o libtest1.so
- $ gcc test.c -fPIC -shared -o libtest.so -L. -ltest1
這樣你在當前目錄下就會看到有一個libtest.so和libtest1.so文件生成了，其中litest.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，這會有什么影響嗎?我們后面就會看到。
鏈接時查找路徑
我們都知道，在編譯成可執行文件前，鏈接器鏈接動態庫也是需要查找動態庫路徑的，否則怎么鏈接上指定的動態庫呢?那么這個順序又是怎樣的呢?
首先會查找的會是編譯時鏈接的路徑。修改前面的main.c，讓它調用libtest.so中的test函數：
- // 來源：公眾號【編程珠璣】
- #include <stdio.h>
- #include "test.h"
- int main()
- {
- test(); // 調用libtest.so中的test函數
- return 0;
- }
編譯鏈接：
- $ gcc -o main main.c -I ./ -L./ -ltest -ltest1
完美編譯過。除此之外，如果我們把libtest.so和libtest1.so都移到/usr/lib下面，我們發現，即便不用-L也能編譯過了:
- $ gcc -o main main.c -I ./ -ltest -ltest1
這里需要說明的是，我們通過-L./來指定搜索庫的路徑，由于libtest.so依賴libtest1.so，因此在編譯鏈接時，也需要鏈接上test1。
小結
從上面的內容可以看到，在鏈接時，我們通過-L參數搜索要鏈接的庫路徑，但是這個路徑信息不會寫到ELF文件中，因此你會通過ldd命令看到not found，而通過-rpath可以指定鏈接時的搜索路徑，這個信息會寫入到ELF文件中，最終看到的結果是，由于libtest.so依賴libtest1.so，所以其他程序依賴libtest.so時，會自動從寫入ELF的rpath中搜索它依賴的其他庫，因此只需要鏈接libtest即可，例如：
在制作庫libtest1.so時，加上-rpath-link選項：
- $ 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也鏈接進來了。
當然了，如果-L指定的路徑沒有呢,它還會去查找其他地方，否則依賴的系統庫怎么找到呢?總結大致順序如下：
- -L指定鏈接路徑
- 對于依賴庫中依賴的搜索順序通過-rpath-link或-rpath選項查找(后面會提到)
- gcc默認鏈接路徑(gcc --print-search-dir | grep libraries 查看)
- 鏈接器配置的查找路徑(ld -verbose | grep SEARCH_DIR查看)
針對具體的系統或鏈接器，可能有些差異，但是大致如此。
運行時查找路徑
雖然前面編譯成功了，但是我們運行看看，發現運行失敗了。
- $ ./main
- ./main: error while loading shared libraries: libtest.so: cannot open shared object file: No such file or directory
其實我們用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環境變量
這個環境變量在介紹《性能優化-使用高效內存分配器》中的時候，也有提到，用來做測試非常方便，同樣的，這種方式也最好僅僅只是用于測試，因為它的優先級非常高，并且影響全局。使用也很簡單：
- $ export LD_PRELOAD=./libtest.so
- $ ./main
為了避免影響后面的驗證，這里取消設置該環境變量：
- unset LD_PREALOD
查找rpath路徑
上面的情況是找不到動態庫，那么它首先會去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環境變量
另外也可以通過這個環境變量來設置要搜索庫的路徑。
- $ gcc -o main main.c -L . -ltest
- $ export LD_LIBRARY_PATH=./
- $ ./main
這樣運行也是沒有問題的。
同樣，為了避免對后面測試產生影響，取消設置該環境變量：
- unset LD_LIBRARY_PATH
/etc/ld.so.conf中的路徑
我的機器上這個文件的內容如下：
- $ 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
所以它實際指的是/etc/ld.so.conf.d/目錄下所有conf路徑包含路徑，打開其中一個libc.conf，它里面包含的路徑為：
- $ /usr/local/lib
既然如此，我們把前面的libtest.so復制到該目錄下(可能需要sudo權限)：
- $ sudo cp libtest.so /usr/local/lib
- $ sudo ldconfig
- $ ./main
- I am test；hello，編程珠璣
- test1,needed by test
注意，這里拷貝完成后，需要執行ldconfig，它會更新相應的共享庫，以便可執行程序能夠找到。實際上，執行完成后，你確實就能在/etc/ld.so.cache文件中找到：
- $ grep -a libtest.so /etc/ld.so.cache
同樣，為了影響后面測試，記得刪除：
- rm /usr/local/lib/libtest.so
實際上這里是先從/etc/ld.so.cache中的路徑查找，然后再從ld.so.conf的路徑中查找。后面我們可以通過命令看到。
/usr/lib，/lib/
當然了，如果以上路徑都沒有，最終還會在lib或/usr/lib下找，為了驗證，我們將庫拷貝到/lib目錄下
- $ cp libtest.so /lib
- $ ./main
- I am test；hello，編程珠璣
- test1,needed by test
同樣能正常運行。
小結
小結一下，動態庫的搜索順序如下：
- LD_PRELOAD環境變量指定庫路徑
- -rpath鏈接時指定路徑
- LD_LIBRARY_PATH環境變量設置路徑
- /etc/ld.so.conf配置文件指定路徑
- 默認共享庫路徑，/usr/lib，lib
以上這些查找路徑你很容易來驗證它們的優先級，簡單的做法就是這幾個位置分別放置同名不同作用的庫，來看看它到底先使用哪個路徑下的庫，可自行嘗試。
LD_DEBUG
這個環境通常用來調試。例如，查看整個裝載過程：
- $ 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
總結
了解動態庫的搜索路徑，可以在開發中很好的幫助你定位找不到庫的問題，同時LD_DEBUG環境變量也能夠很好的幫助你調試，例如查看庫搜索的路徑，顯示符號的查找過程等等。
雖然程序運行能夠有多種途徑獲取動態庫路徑，但是并不是每種方式都合適，有的方式甚至完全不該用，但這超出了本文的討論范圍了。有興趣的也可以點擊閱文原文，查看《Why LD_LIBRARY_PATH is bad》
