Linux下動態(tài)庫相關知識

Linux 下有動態(tài)庫和靜態(tài)庫，動態(tài)庫以.so為擴展名，靜態(tài)庫以.a為擴展名。二者都使用廣泛。本文主要講動態(tài)庫方面知識。

鏈接了冗余的庫會怎樣？

基本上每一個linux 程序都至少會有一個動態(tài)庫，查看某個程序使用了那些動態(tài)庫，使用ldd命令查看

這么多so，是的。使用ldd顯示的so，并不是所有so都是需要使用的，下面舉個例子：

main.cpp

使用缺省參數(shù)編譯結果

如果我鏈接一些so，但是程序并不用到這些so，又是什么情況呢？下面我加入鏈接壓縮庫，數(shù)學庫，線程庫

看看，雖然沒有用到，但是一樣有鏈接進來，那看看程序啟動時候有沒有去加載它們呢？

看，有加載?。。?/p>

所以必定會影響進程啟動速度，所以我們最后不要把無用的so編譯進來，這里會有什么影響呢？

大家知不知道linux從程序（program或?qū)ο螅┳兂蛇M程（process或進程），要經(jīng)過哪些步驟呢，這里如果詳細的說，估計要另開一篇文章。簡單的說分三步：

1、fork進程，在內(nèi)核創(chuàng)建進程相關內(nèi)核項，加載進程可執(zhí)行文件；

2、查找依賴的so，一一加載映射虛擬地址

3、初始化程序變量。

可以看到，第二步中dll依賴越多，進程啟動越慢，并且發(fā)布程序的時候，這些鏈接但沒有使用的so，同樣要一起跟著發(fā)布，否則進程啟動時候，會失敗，找不到對應的so。所以我們不能像上面那樣，把一些毫無意義的so鏈接進來，浪費資源。但是開發(fā)人員寫makefile 一般有沒有那么細心，圖省事方便，那么有什么好的辦法呢。繼續(xù)看下去，下面會給你解決方法。

先使用 ldd -u demo 查看不需要鏈接的so，看下面，一面了然，無用的so全部暴露出來了吧

使用-Wl,--as-needed 編譯選項

呵呵，辦法很簡單省事吧，本文主要講so依賴的一些問題，下面將介紹so的路徑方面一些不為人知的小秘密。

庫路徑不為人知的小秘密

我們知道Linux鏈接so有兩種途徑：顯示和隱式。所謂顯示就是程序主動調(diào)用dlopen打開相關so;這里需要補充的是，如果使用顯示鏈接，上篇文章討論的那些問題都不存在。首先,dlopen的so使用ldd是查看不到的。其次，使用dlopen打開的so并不是在進程啟動時候加載映射的，而是當進程運行到調(diào)用dlopen代碼地方才加載該so，也就是說，如果每個進程顯示鏈接a.so;但是如果發(fā)布該程序時候忘記附帶發(fā)布該a.so,程序仍然能夠正常啟動，甚至如果運行邏輯沒有觸發(fā)運行到調(diào)用dlopen函數(shù)代碼地方。該程序還能正常運行，即使沒有a.so.

既然顯示加載這么多優(yōu)點，那么為什么實際生產(chǎn)中很少碼農(nóng)使用它呢,主要原因還是起使用不是很方便，需要開發(fā)人員多寫不少代碼。所以不被大多數(shù)碼農(nóng)使用，還有一個重要原因應該是能提前發(fā)現(xiàn)錯誤，在部署的時候就能發(fā)現(xiàn)缺少哪些so，而不是等到實際上限運行的時候才發(fā)現(xiàn)缺東少西。

下面舉個工作中最常碰到的問題，來引申出本篇內(nèi)容吧。

寫一個最簡單的so，tmp.cpp

編譯=>鏈接=》運行,下面指令中的main.cpp請參見前文。

[stevenrao]$ g++ -fPIC -c tmp.cpp

[stevenrao]$ g++ -shared -o libtmp.so tmp.o

[stevenrao]$ mv libtmp.so /tmp/

[stevenrao]$ g++ -o demo -L/tmp -ltmp main.cpp

[stevenrao]$ ./demo

./demo: error while loading shared libraries: libtmp.so: cannot open shared object file: No such file or directory

[stevenrao]$ ldd demo

linux-vdso.so.1 => (0x00007fff7fdc1000)

libtmp.so => not found

這個錯誤是最常見的錯誤了。運行程序的時候找不到依賴的so。一般人使用方法是修改LD_LIBRARY_PATH這個環(huán)境變量

export LD_LIBRARY_PATH=/tmp

[stevenrao]$ ./demo

test

這樣就OK了,不過這樣export只對當前shell有效，當另開一個shell時候，又要重新設置。可以把export LD_LIBRARY_PATH=/tmp語句寫到~/.bashrc中，這樣就對當前用戶有效了，寫到/etc/bashrc中就對所有用戶有效了。

前面鏈接時候使用-L/tmp/ -ltmp是一種設置相對路徑方法，還有一種絕對路徑鏈接方法。

[stevenrao]$g++ -o demo/tmp/libtmp.so main.cpp

[stevenrao]$./demo

test

[stevenrao]$ldd demo

linux-vdso.so.1 =>(0x00007fff083ff000)

/tmp/libtmp.so (0x00007f53ed30f000)

絕對路徑雖然申請設置環(huán)境變量步驟，但是缺陷也是致命的，這個so必須放在絕對路徑下，不能放到其他地方，這樣給部署帶來很大麻煩。所以應該禁止使用絕對路徑鏈接so。

搜索路徑分兩種，一種是鏈接時候的搜索路徑，一種是運行時期的搜索路徑。像前面提到的-L/tmp/是屬于鏈接時期的搜索路徑，即給ld程序提供的編譯鏈接時候?qū)ふ覄討B(tài)庫路徑；而LD_LIBRARY_PATH則既屬于鏈接期搜索路徑，又屬于運行時期的搜索路徑。

這里需要介紹鏈-rpath鏈接選項，它是指定運行時候都使用的搜索路徑。聰明的同學馬上就想到,運行時搜索路徑，那它記錄在哪兒呢。也像LD_LIBRARY_PATH那樣，每部署一臺機器就需要配一下嗎。呵呵，不需要..,因為它已經(jīng)被硬編碼到可執(zhí)行文件內(nèi)部了?？纯聪旅嫜菔?/p>

1. [stevenrao] $ g++ -o demo -L /tmp/ -ltmp main.cpp

2. [stevenrao] $ ./demo

3. ./demo: error while loading shared libraries: libtmp.so: cannot open shared object file: No such file or directory

4. [stevenrao] $ g++ -o demo -Wl,-rpath /tmp/ -L/tmp/ -ltmp main.cpp

5. [stevenrao] $ ./demo

6. test

7. [stevenrao] $ readelf -d demo

8.

9. Dynamic section at offset 0xc58 contains 26 entries:

10. Tag Type Name/Value

11. 0x0000000000000001 (NEEDED) Shared library: [libtmp.so]

12. 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]

13. 0x0000000000000001 (NEEDED) Shared library: [libm.so.6]

14. 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]

15. 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]

16. 0x000000000000000f (RPATH) Library rpath: [/tmp/]

17. 0x000000000000001d (RUNPATH) Library runpath: [/tmp/]

看是吧，編譯到elf文件內(nèi)部了，路徑和程序深深的耦合到一起。