Could not read symbols解決方案

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 中指明庫的搜尋路徑是否有誤

Could not read symbols擴充
　　

      具體的編譯環境和選項錯綜複雜，如果通過上述方法仍存在錯誤，可以將錯誤資訊，Makefile，configure等貼至一些知名的Linux技術論壇，以尋求更具體的協助

本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/cserchen/archive/2010/04/22/5515974.aspx