故事原因1， -fPIC與-Wl,Bsymbolic參數(shù)
今天有些工作沒有做完岁忘，想趁星期一聯(lián)調(diào)的時候解決一下蕴侣。發(fā)現(xiàn)在編譯自己的so的時候，總是提示錯誤：
R64_pc32_xx against ..., need to be recompiled with fPIC.
由于編譯的so文件中使用了ffmpeg臭觉，提示的正是libavcodec.a其中的.o文件昆雀。
按網(wǎng)上的提示重新編譯ffmpeg，比較正常的版本如下蝠筑。
./configure --enable-pic --disable-yasm --disable-crystalhd --disable-vaapi
但是并沒有完全解決上面的問題狞膘。
其中要加一個-wl,Bsymbolic，也就是在自己的so在鏈接的時候要強制自己使用本地的函數(shù)什乙？
找到的解釋如下：
在創(chuàng)建動態(tài)鏈接庫時挽封，gcc/g++選項中添加編譯選項
-Wl,-Bsymbolic.
其中Wl表示將緊跟其后的參數(shù)，傳遞給連接器ld臣镣。Bsymbolic表示強制采用 本地的全局變量定義辅愿，這樣就不會出現(xiàn)動態(tài)鏈接庫的全局變量定義被應(yīng)用程 序/動態(tài)鏈接庫中的同名定義給覆蓋了！
如果不想讓主程序能存取動態(tài)庫里的全局變量忆某，則在鏈接動態(tài)連接庫的時候点待，給gcc傳入-Wl,-Bsymbolic即可
-Bsymbolic 當(dāng)創(chuàng)建動態(tài)庫時，如果某一個符號在全局符號表中已經(jīng)存在弃舒，強制采用本地的癞埠；而缺省情況下，本地定義會被覆蓋聋呢。這一點苗踪，對于保證多個動態(tài)庫之間互不影響是很重要的，起碼削锰，它保證了本地定義的優(yōu)先性通铲，不會在程序員不知情的時候，偷偷用外部定義換掉器贩。此外颅夺，如果想保證某一個動態(tài)庫不會影響其他的動態(tài)庫央串，則可以采用后面談到的version-script選項；
但是這個為什么就解決了問題碗啄，還是不是非常清楚。
事故原因2稳摄，GCC的庫依賴連接順序的講究
libswresample.a的位置有講究稚字，要放在比如說libavutil.a libavcodec.a等的后面
編譯器的連接尋找重定位機制是有缺陷的嗎？比如找不到swr_alloc厦酬，而實際上這個函數(shù)的實現(xiàn)是在libswresample.a中有實現(xiàn)的胆描。
這個搜了一下，確實gcc有這個缺陷仗阅，被依賴的庫要往后放昌讲，如果兩個庫相互依賴，那真的郁悶了减噪。
在鏈接靜態(tài)庫時短绸，如果多個靜態(tài)庫之間存在依賴關(guān)系，則有依賴關(guān)系的靜態(tài)庫之間存在鏈接順序問題筹裕。這在使用靜態(tài)庫時需要注意醋闭，否則會報符號找不到的鏈接錯誤。 例如：lib2.a 依賴于 lib1.a朝卒，而最終可執(zhí)行文件 test 依賴于 lib2.a证逻，則鏈接選項應(yīng)為：-llib2.a -llib1.a，而不能反過來抗斤，否則會報 lib1.a 中的某些符號未定義囚企。
如果互相依賴這里有個解決的辦法
你可能最終采取丑陋的做法,將其中一個庫在前后放兩次:gcc -o out.bin liba.ar libb.ar liba.ar -lrt
還有xlinker的辦法：
最終的做法:gcc -o output.bin -Xlinker "-(" liba.ar libb.ar -Xlinker "-)" -lrt這樣可以解決庫順序的問題了！問題是瑞眼，如果你的庫相互間的依賴如果錯綜復(fù)雜的話龙宏，可能會增加連接的時間，不過伤疙，做架構(gòu)設(shè)計的都應(yīng)該能考慮到這些問題吧烦衣。
其他的一些小的tips
- cp --force可以強制覆蓋，但是要是同一個用戶掩浙，不然也是沒什么卵用的花吟。
- rz --be可以解決zmodem connection timeout的問題。要記得add把文件加上厨姚。
- 還試著編譯了以下boost庫衅澈，希望能在本地的虛擬機器上搭建出完整的環(huán)境。但是boost從1.33到1.58現(xiàn)在的編譯方法都不一樣谬墙。
舊的版本為./build.sh,而新的版本為./bootstrap.sh今布，都是要先編譯出bjam经备，但是在gcc下還是有很多error，unexpected token的錯誤部默。這個問題沒有得到比較好的解決侵蒙。
