程序鏈接碰到的奇怪問題

changyongID

大家好 ,碰到一個奇怪的問題,現(xiàn)把問題描述如下:

把一些代碼的源文件編譯鏈接后做成庫,分別生成靜態(tài)庫.a和動態(tài)庫.so

然后寫程序去調(diào)用庫中的函數(shù)..編譯時生成可執(zhí)行文件.  

現(xiàn)在卻發(fā)現(xiàn),當編譯時鏈接靜態(tài)庫.a時能夠正確執(zhí)行(靜態(tài)編譯)

而動態(tài)鏈接.so時,生成的可執(zhí)行文件卻執(zhí)行報錯,報的錯誤是經(jīng)典的 "Segmentation fault"

起初還懷疑是makefile里寫的不正確,導致有的.o文件沒有連接到.so里.

但仔細檢查了makefile里,生成庫的兩句為:

$(LIBRARY_FILE) : $(OBJECTS)    #生成靜態(tài)庫
        $(AR) crs $(LIBRARY_FILE) $(OBJECTS)

$(SHARED_LIBRARY_FILE) : $(OBJECTS) #生成動態(tài)庫
        $(CC) -fpic -shared -o $(SHARED_LIBRARY_FILE) $(OBJECTS)

由這兩句可以說明生成的靜態(tài)庫和動態(tài)庫都是由相同的.o文件生成的.
請教有沒有人知道發(fā)生這種現(xiàn)象的原因? 謝謝

sunlan

用ldd 檢查一下看是否調(diào)用了正確的動態(tài)庫

changyongID

回復二樓: 已用ldd看過,鏈接沒有問題..

進一步觀察,發(fā)現(xiàn)更加奇怪了..

編譯庫后生成靜態(tài)庫 liba1.a , liba2.a , liba3.a
     相應生成動態(tài)庫  liba2.so, liba2.so, liba3.so

然后,我的主程序 main.c 在編譯時要去鏈接庫..

1. 如果main.c采取靜態(tài)編譯的方式,編譯時鏈接靜態(tài)庫 liba1.a , liba2.a , liba3.a,
  則最后生成可執(zhí)行文件 main 為30多M(靜態(tài)編譯將所有的都弄進來了)...此時可以正確執(zhí)行程序的所有功能.

2. 如果main.c采取動態(tài)編譯的方式編譯時鏈接動態(tài)庫  liba2.so, liba2.so, liba3.so
最后生成的可執(zhí)行文件為幾百k, 然后將這三個庫liba2.so, liba2.so, liba3.so用ldconfig設置一下,使得程序運行時能正確加載它們.
但此時生成的可執(zhí)行文件main卻有某些功能運行時出現(xiàn)"段錯誤", 而另外一些功能又能正確運行.

這難道說明動態(tài)庫里有一些"符號"不存在,動態(tài)加載時不能找到它???

ps:上面說明兩個可執(zhí)行程序大小的差異,是為了請教:
1. 可否在靜態(tài)編譯時將不會用到的函數(shù)去掉,不鏈接進來,減小可執(zhí)行程序的大小?
2. 這樣生成的靜態(tài)庫與動態(tài)庫,難道其中有些函數(shù)是靜態(tài)庫有,而動態(tài)庫不存在的?(一直覺得相同的 .o文件生成的靜動態(tài)庫里的"符號"應該相同,此時懷疑了.)


請達人指點一下錯誤? (或還需要我提供哪些信息?)

rain_fish

看lz的庫名字，應該是在實驗，能不能把代碼貼出來，大家研究一下？

prolj

跟.o一起連接吧，還可以strip。

drangon

你是在什么平臺下編譯的？linux（RHEL 4.8？RHEL5.4？OPENSUSE 11.2？）？FreeBSD？OpenSolaris？AIX？HP Unix？

你用的是什么編譯器？（gcc 3.x？gcc4.x？hp cc？）

生成 $(OBJECTS) 用的是什么參數(shù)？試試統(tǒng)一使用 -DPIC -fPIC

zxrjkl

1.靜態(tài)鏈接本來就只會鏈接用到的函數(shù)，不用到的是不會鏈接進來的
你的問題我懷疑是代碼本身有問題，導致錯誤；
因為生成的靜態(tài)庫與動態(tài)庫的代碼會有一些區(qū)別；
但這些區(qū)別應該只在尋址方式上有區(qū)別，如動態(tài)庫必須生成位置無關(guān)代碼

changyongID

謝謝樓上幾位的回復.

to 4#rain_fish: 我上面打出的幾個庫名是為了描述問題更清楚. 源代碼是c++的代碼,其代碼量非常大.不太好貼.

to 5#prolj: 如果我的主程序跟庫生成的.o一起鏈接,這樣就不是靜態(tài)編譯了吧...而且現(xiàn)在的問題是主程序里沒有問題,只是改變編譯時鏈接的方法(分別用靜態(tài)鏈接和動態(tài)鏈接), 這樣就導致了不同的運行結(jié)果,這也太奇怪了.
更為奇怪的是,動態(tài)鏈接的情況下,部分功能是正常的,只有某個功能運行時出現(xiàn)"段錯誤".

to 6#drangon: 我的平臺是 linux: fedora 11 , gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC)
最后生成動態(tài)庫用的是

$(SHARED_LIBRARY_FILE) : $(OBJECTS) #生成動態(tài)庫
        $(CC) -fpic -shared -o $(SHARED_LIBRARY_FILE) $(OBJECTS)


to 7#zxrjkl: 因為很奇怪,動態(tài)鏈接時,有的功能可以,某個功能就不行..我跟蹤了一下源代碼,發(fā)現(xiàn)跟到某一個函數(shù)里出現(xiàn)段錯誤.. 比如這里,我跟到一個 get()函數(shù)里之后遇到段錯誤..但此時,令我不解的是,難道靜態(tài)庫跟動態(tài)庫有這方面的差別?為什么靜態(tài)庫鏈接后就不出錯,而動態(tài)庫就會有點問題呢?

ps:前面幾貼都忘記說明:庫文件和主程序的源代碼都是c++的.

prolj

查看斷錯誤那個功能的代碼的所有內(nèi)存操作，尤其是數(shù)組。

changyongID

謝謝prolj, 其實我也是想查到相應函數(shù)..

但是無奈, 對c++不熟, 什么繼承, 多態(tài), 弄得我都有點快吐了...

我用kscope查看代碼,再往程序里添加一些打印信息, 這樣的方法跟了幾層函數(shù)...現(xiàn)在勉強跟蹤到一個get()函數(shù)
里..

不知道gdb可否用來調(diào)試這類錯誤???

另外, 請問一下, 跟蹤c++源碼用什么比較好? 現(xiàn)在用的kscope實際上的機制跟vim + ctags一樣..