一、案例
???? 編譯出一個(gè)動(dòng)態(tài)庫(kù).libXXXEngine.so。然后直接在另一個(gè)工程中，把頭文件include進(jìn)來(lái)，并link到該庫(kù)：-lXXXEngine.
嘗試編譯，出錯(cuò)：
.//libXXXEngine.so:undefined reference to`CHttpParser::GetCurrentHttpMethod(http_method_t&)'
?
.//libGenaEngine.so: undefined reference to `CHttpParser::CHttpParser(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'
.//libGenaEngine.so: undefined reference to `CHttpParser::ExactResultFromHttpMsgBody(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
.//libGenaEngine.so: undefined reference to `CHttpParser::parse(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'
collect2: ld returned 1 exit status
從描述上看，以下四個(gè)函數(shù)沒(méi)有定義：
?
（1） CHttpParser::GetCurrentHttpMethod(http_method_t&)
（2）CHttpParser::CHttpParser(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)
（3）CHttpParser::ExactResultFromHttpMsgBody(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
（4）CHttpParser::parse(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)
?
然而奇怪的是，當(dāng)我跟進(jìn)libXXXengine.so的具體代碼時(shí)，卻發(fā)現(xiàn)頭文件和源文件的定義和聲明都可以找到。
那么究竟什么原因呢？
二 問(wèn)題分析
??? 出現(xiàn)這種錯(cuò)誤，有幾個(gè)原因：
（1）一是使用者自己定義的函數(shù)或者全局變量所在源代碼文件，沒(méi)有被編譯、連接。
（2）一是使用者自己定義的函數(shù)或者全局變量沒(méi)有定義。
（3） 未定義的符號(hào)是一個(gè)動(dòng)態(tài)庫(kù)函數(shù)，在源程序中使用了該庫(kù)函數(shù)，而連接過(guò)程中還沒(méi)有給定相應(yīng)的函數(shù)庫(kù)的名稱(chēng)，或者是該檔案庫(kù)的目錄名稱(chēng)有問(wèn)題.
即：.so文件沒(méi)有把所有需要的庫(kù)都鏈接上。使用了庫(kù)中定義的實(shí)體，但沒(méi)有指定庫(kù)（-lXXX）或者沒(méi)有指定庫(kù)路徑（-LYYY），會(huì)導(dǎo)致該錯(cuò)誤,
（4）C/C++相互依賴(lài)和鏈接
gcc和g++編譯結(jié)果的混用需要保證能夠extern "C" 兩邊都可以使用的接口,在我們的64位環(huán)境中g(shù)cc鏈接g++的庫(kù)還需要加上 -lstdc++。
???? 經(jīng)排查，我們?cè)趍akefile中通過(guò)-lXXEngine正確鏈接了libXXXEngine.so，同時(shí)，我們也把相應(yīng)的頭文件放到我當(dāng)前工程目錄下了。然而，被告知且出錯(cuò)的函數(shù)都是在動(dòng)態(tài)庫(kù)中的。好奇怪！
??? 為了進(jìn)一步找到問(wèn)題的root cause,我們使用了nm命令來(lái)進(jìn)一步排查：
nm libXXXEngine.so |grep?
C
HttpParser
?
????????????? U _ZN11CHttpParser20GetCurrentHttpMethodER13http_method_t
???????????????? U _ZN11CHttpParser26ExactResultFromHttpMsgBodyESsRSs
???????????????? U _ZN11CHttpParser5parseESs
???????????????? U _ZN11CHttpParserC1ESs
00000000000134e6 W _ZN5boost10shared_ptrI11CHttpParserE4swapERS2_
0000000000012e56 W _ZN5boost10shared_ptrI11CHttpParserEC1ERKS2_
0000000000012e30 W _ZN5boost10shared_ptrI11CHttpParserEC1Ev
0000000000014cda W _ZN5boost10shared_ptrI11CHttpParserEC1IS1_EEPT_
0000000000012cda W _ZN5boost10shared_ptrI11CHttpParserED1Ev
0000000000013df4 W _ZN5boost10shared_ptrI11CHttpParserEaSERKS2_
000000000001348b W _ZN5boost14checked_deleteI11CHttpParserEEvPT_
0000000000014c4c W _ZN5boost6detail12shared_countC1I11CHttpParserEEPT_
0000000000013bae W _ZN5boost6detail17sp_counted_impl_pI11CHttpParserE11get_deleterERKSt9type_info
0000000000013b92 W _ZN5boost6detail17sp_counted_impl_pI11CHttpParserE7disposeEv
0000000000013452 W _ZN5boost6detail17sp_counted_impl_pI11CHttpParserEC1EPS2_
0000000000014d1e W _ZN5boost6detail17sp_counted_impl_pI11CHttpParserED0Ev
0000000000014d5a W _ZN5boost6detail17sp_counted_impl_pI11CHttpParserED1Ev
000000000001591c W _ZNK5boost10shared_ptrI11CHttpParserEptEv
00000000000134b4 W _ZSt4swapIP11CHttpParserEvRT_S3_
000000000021ba40 V _ZTIN5boost6detail17sp_counted_impl_pI11CHttpParserEE
0000000000017420 V _ZTSN5boost6detail17sp_counted_impl_pI11CHttpParserEE
000000000021ba00 V _ZTVN5boost6detail17sp_counted_impl_pI11CHttpParserEE
0000000000017100 r _ZZNK5boost10shared_ptrI11CHttpParserEptEvE19__PRETTY_FUNCTION__
?
?
命令輸出結(jié)果顯示，那些報(bào)錯(cuò)的函數(shù)的符號(hào) 同樣可以在nm里找到。
不同的是，這四個(gè)出錯(cuò)的函數(shù)，輸出的前半部分為空。
這就是異常和問(wèn)題所在！
?
下面我們只要對(duì)nm命令稍作了解：
nm命令還是比較簡(jiǎn)單而且強(qiáng)大的。它用來(lái)列出一個(gè)目標(biāo)文件中的各種符號(hào)。符號(hào)的種類(lèi)很多，以下是一些常見(jiàn)的符號(hào)類(lèi)型
|
nm輸出字符
|
含義
|
|
R
|
Read only symbol. 比如在代碼中有一個(gè)const MAXDATA = 3095; 則MAXDATA就是一個(gè)Read only symbol
|
|
N
|
這是一個(gè)調(diào)試符號(hào)
|
|
D
|
這是一個(gè)已經(jīng)初始化的變量的符號(hào)。比如代碼中int i = 1和char *str = "Hello"則i和str都是這種類(lèi)型的符號(hào)
|
|
T
|
Text段的符號(hào)。子程序都是這種符號(hào)，比如文件中實(shí)現(xiàn)了一個(gè)函數(shù)function，則function就是這種符號(hào)
|
|
U
|
未定義的符號(hào)。如果文件中引用了不存在的函數(shù)，則這些未定義的函數(shù)符號(hào)就是這種類(lèi)型
|
|
S
|
未初始化的符號(hào)，比如全局變量int s;則s的符號(hào)就是此類(lèi)型
|
nm命令的詳細(xì)用法以及例子見(jiàn)正文。
?
至此，我們可以推斷：動(dòng)態(tài)庫(kù)中有未定義的符號(hào)，說(shuō)明該動(dòng)態(tài)庫(kù)的編譯有問(wèn)題，即是如下原因之一：
（1）一是使用者自己定義的函數(shù)或者全局變量所在源代碼文件，沒(méi)有被編譯、連接。
（2）一是使用者自己定義的函數(shù)或者全局變量沒(méi)有定義。
這種問(wèn)題的解決，首先就要檢查動(dòng)態(tài)庫(kù)的makefile寫(xiě)的是否有問(wèn)題。
果然，發(fā)現(xiàn)makefile里沒(méi)有把該出錯(cuò)函數(shù)所在的定義的源文件沒(méi)有編譯進(jìn)去。
?
?
三?問(wèn)題解決
???? 找到了原因，問(wèn)題解決就方便了。修改.so的makefile即可。
svn diff
-COM_SRCS := $(GENASRCDIR)/CGenaEngine.cpp
+COM_SRCS := $(GENASRCDIR)/CGenaEngine.cpp?? $(HTTPSRCDIR)/CHttpMiniParser.cpp?? -----》把CHttpMiniParser.cpp??編譯進(jìn)去。
?