（by 陳運文）
Could not read symbols介紹
Could not read symbols：Linux/UNIX系統下編譯時，常見的一類報錯信息。通常情況下，該編譯報錯信息之前會給出出現錯誤的靜態庫（.a結尾檔案）、或動態庫（.so結尾檔案），
該報錯的基本原因是當前編譯器無法對庫檔案進行正確的解析
Could not read symbols報錯類型
具體的報錯信息會在Could not read symbols：欄位後給出，常見的一些報警信息形如：/usr/lib/libdemo.so: could not read symbols: File in wrong format
/usr/lib/libz.a: Could not read symbols: Bad value
/usr/lib/libcode.a: Could not read symbols:Invalid operation
/usr/lib/htmlparse.a: could not read symbols: Archive has no index; run ranlib to add one
/usr/lib/htmlparse.a: could not read symbols: malformed archive
Linux出現Could not read symbols報警主要原因為當前編譯環境和庫檔案生成時對應的環境不同，由於Linux本身編譯選項非常複雜，可以從以下幾個方面逐步排查：
Could not read symbols原因和解決方案
1、 gcc/g++版本不正確眾所周知Linux gcc編譯器（GNU Compiler Collection）是功能強大的交叉編譯器，但其眾多的版本會導致兼容問題。如果聯編所使用的 .a/.so檔案是由另一個不同版本的gcc編譯生成後，當移植到另一個不同版本gcc環境下編譯時，（例如：將gcc2.9x老版本下的.so，拷貝入新版gcc環境使用），且編譯版本不兼容，會出現Could not read symbols的報錯。（可以使用gcc -v 查看一下當前版本）
如果是這種原因導致的問題，需要在新gcc版本下，刪除（或更名）舊的庫檔案，重新由src編譯生成.a/.so檔案，保證gcc版本一致
2、64bit/32bit編譯環境不一致
目前Linux OS系統會推出32位和64位兩個不同的版本，此時即使使用命令：
gcc --version
查看的gcc三位版本一致，但由於32位程式和64位程式可能不兼容，因此如果在32bit OS環境下編譯獲得的庫檔案，移植入64bit環境時會產生Could not read symbols錯誤
一個簡單的方式查看當前系統位數：
getconf LONG_BIT
結果顯示：32 or 64
請確定在作業系統位數相同的環境下進行編譯，否則刪除原庫檔案重新生成
3、Makefile配置問題
查看編譯期參數是否缺少 -fPIC ， 不僅是共享庫，靜態庫有時也需要有 -fPIC參數
或者查看Makefile是否存在前後配置項不一致
4、修改configure配置
作業系統位數可能導致的另一個問題是，所使用的底層庫不同
linux系統在 /usr/lib/ 和 /usr/lib64/ 兩個目錄下，會分別存放不同位數版本的lib，
可通過修改環境配置來指定所需的庫位置：
# ./configure --enable-lib64 --libdir=/usr/lib64
解決庫版本問題
已知的一個常見問題是：在64位機器上編譯httpd-2.0.x時常會出現該原因導致的Could not read symbols報錯，通過該方法可解決
另外，64位系統編譯腳本在定位expat上存在問題（編譯apache時常出現），修改configure使用自帶的expat來編譯可解決，具體修改configure配置的方法是增加：
--with-expat=builtin
5、Lib路徑錯誤
目標路徑的庫檔案不存在或不一致，也會導致Could not read symbols錯誤，
可以查看路徑和庫檔案所在位置是否一致，環境變數 LD_LIBRARY_PATH 中指明庫的搜尋路徑是否有誤
