.jpg)
這篇文章主要介紹了 linux 下同名符號(hào)沖突問題解決方案的相關(guān)資料,需要的朋友可以參考下
linux 下同名符號(hào)沖突問題解決方案
最近的工作中遇到如下令人蛋疼的問題：
Linux 下有三個(gè)模塊aa、bb、cc，基本情況如下：
cc 編譯連接得到 cc.so 動(dòng)態(tài)庫，cc 中有如下接口：
cc_fun? {? ……? do();//調(diào)用名為do的cc模塊內(nèi)部函數(shù)? ……? }
bb 編譯連接得到 bb.a 接口庫，bb 中有如下接口：
bb_fun? {? ……? handle?=?dlopen(cc.so,?RTLD_LAZY);//加載cc.so? pccfun?=?dlsym(handle,?“cc_fun”);//獲取cc_fun函數(shù)指針? (*pccfun)();//調(diào)用cc_fun函數(shù)，此時(shí)應(yīng)該會(huì)調(diào)用cc模塊中的do()函數(shù)? do();//調(diào)用名為do的bb模塊內(nèi)部函數(shù)（與cc模塊中的do()函數(shù)同名，實(shí)現(xiàn)卻不相同）? ……? }
aa 編譯后通過 -lbb 鏈接選項(xiàng)的方式連接 bb.a 得到 aa 可執(zhí)行程序，并調(diào)用 bb.a 的接口函數(shù) bb_fun()：
main? {? ……? bb_fun()；//調(diào)用bb_fun函數(shù)? ……? }
工作中發(fā)現(xiàn) aa 在運(yùn)行時(shí)接口異常，總是有內(nèi)存泄露和功能異常，通過定位發(fā)現(xiàn)問題集中在同名的 do() 函數(shù)上。通過輸出打印發(fā)現(xiàn)程序中兩次調(diào)用 do() 函數(shù)都調(diào)用到了 bb 模塊中的 do() 函數(shù)，而 cc 模塊中的 do() 函數(shù)從未被調(diào)用到，導(dǎo)致程序行為異常和內(nèi)存泄露。
后經(jīng)多方查證了解到因?yàn)?linux 程序中各個(gè)庫中的符號(hào)表最終都會(huì)加載到程序所在的全局符號(hào)表中，此時(shí)如果有同名符號(hào)就只能調(diào)用到第一個(gè)加載進(jìn)來的符號(hào)，也就是說后邊加載的同名符號(hào)都會(huì)被之前的覆蓋。cc 模塊中的 do() 函數(shù)被 bb 模塊中的 do() 函數(shù)覆蓋了，所以無法被調(diào)用到。
廢話不多說。。。
在試驗(yàn)過很多不滿意的方法之后，最終的解決方法如下：
1.在 cc 的 makefile 中加入 -Wl,-Bsymbolic -Wl,–version-script,version 的連接選項(xiàng)，意思是用 version 文件中的腳本指定其導(dǎo)出哪些函數(shù)。
2.version 文件的實(shí)現(xiàn)如下：
VERS{? global:? cc_fun;? local:?*;? };
意思是指定 cc 模塊只導(dǎo)出接口函數(shù) cc_fun，其余函數(shù)都設(shè)為 local 不做導(dǎo)出。
將該文件保存在 makefile 所在目錄即可。
3.重新編譯連接三個(gè)模塊，問題解決。
.png)
