2011年12月19日 星期一

解決 undefined symbol / reference

C++ 新手上路, 有錯還請幫忙指正。

基本觀念

相較於 script language 或 Java 來說, C/C++ 有完整的「編譯 -> 連結 -> 執行」三個階段, 各階段都可能發生 undefined symbol。在解決惱人的 undefined symbol 前, 得先明白整個編譯流程:

  1. 編譯 .c / .cpp 為 .o (object file) 時, 需要提供 header 檔 (用到 gcc 參數 -I)。事實上, 在編譯單一檔案時, gcc/g++ 根本不在意真正的 symbol 是否存在, 反正有宣告它就信了, 所以有引對 header 即可。這也是可分散編譯的原因 (如 distcc ), 程式之間在編譯成 .o 檔時, 並沒有相依性。
  2. 用 linker (ld 或 gold) 將 *.o 連結成 dynamic library 或執行檔時, 需要提供要連結的 library (用到 gcc 參數 -L 指定目錄位置, 用 -l 指定要連什麼函式庫)。不同於前一步, 此時 symbol 一定要在。
  3. 執行的時候, 會再動態開啟 shared library 讀出 symbol。換句話說, 前一個步驟只是檢查是否有。檢查通過也連結成 executable 或 shared library 後, 若執行時對應的檔案不見了, 仍會在執行期間找不到 symbol。若位置沒設好, 可能需要用 LIB_LIBRARY_PATH 指定動態函式的位置, 但不建議這麼做, 最好在執行 linker 時就指定好位置。原因見《Why LD_LIBRARY_PATH is bad》

明白這點後, 就看 undefined symbol 發生在那個階段, 若是編 object file 時發生, 就是沒和編譯器說 header 檔在那, 記得用 -I 告訴它。若在 linking 時發生, 就要同時設好 -L 和 -l。不過難就難在要去那找 undefined symbol 的出處。

解決問題的流程

首先是判斷 symbol 是不是自己用到的原始碼裡, 可配合 id-utils 找看看 (我是用 gj, 比較方便一點)。或是看有沒有 man page, 有 man page 的話, 裡面會記錄用到的 header 和該怎麼下連結參數。若在專案裡找不到, 再用 Google 搜看看 symbol, 運氣好可能會找到套件名稱, 運氣不好.....目前還不知怎麼處理較好, 目前是四處亂翻看看。如果是網路上找來的程式碼, 別人已附好正確的 include 了, 這時用 apt-file search HEADER_PATH 就能找到套件名稱 ( 記得先跑 apt-file update 更新資料庫 ), 比方說: apt-file search openssl/rsa.h 會得到 libssl-dev: /usr/include/openssl/rsa.h。

在 Ubuntu 上, 通常需要裝 X-dev 以取得 header 檔。若是已經裝好套件了, 可用 dpkg --searchlocate 或是 dpkg -L PKG_NAME 找出 header 位置。

若編譯過但 linking 時出錯, 要做進一步分析, 先看是那一個程式用到 undefined symbol。不管是自己的程式出錯, 或是用到的函式庫出錯, 都可從對應的原始碼找到編譯時用的 header X.h。

  • 先看有沒有 man page, 有的話, 裡面會寫該下什麼參數連結。像 man sqrt 會看到說要 "Link with -lm" (記得裝 manpages-dev)
  • 若 X.h 是自己的, 就在附近找看看原始碼在那, 有沒有編譯到。
  • 若 X.h 放在系統目錄裡, 可用 apt-file search X.h 找出 library 的可能出處 ( 記得先跑 apt-file update 更新資料庫 )。接著可用下列方式之一找出函式庫的可能位置:
    • dpkg --search SUBSTRING_OF_LIBRARY_NAME
    • dpkg -L PKG_NAME | grep lib
    • locate SUBSTRING_OF_LIBRARY_NAME # 記得先跑 updatedb

若知道函式庫的確切名稱, 且有 pkg-config 的資訊的話, 可用 pkg-config --libs LIBRARY_NAME 直接找出 gcc/g++ linking 時該下的參數 (附帶一提, 用 --cflags 找出編譯時用到的參數, 像是 -I 接的)。不然, 用其它方式找到函式庫位置後, 要依 -L-l 的規則寫下參數。記得 -l 後接的名稱不用加 "lib", 像 libm.so 是用 -lm。

實際寫較具規模的專案時, 可能不會用手刻 makefile, 要視自己用的整合工具, 將找到的資訊加入整合工具中。

其它相關資訊

  • 可配合 nm LIBRARY 查看 symbol, man nm 有各狀態說明, U 表示 undefined。若該函式應該要出自該函式庫, 卻標為 U, 表示該函式庫一開始就沒編好, 要重編該函式庫。反之, 若該函式定義在外部函式庫, 則是連結時出錯。
  • nm 只適用 static library 或未 strip 前的 shared library。strip 後的 shared lib 得用 readelf -Ws 來看, 這個情境下沒 nm 簡單易讀。(2014-10-27 更新: 也可用 nm -D)
  • 函式庫有 U 通常是正常的, 編執行檔或 dynamic library 時才要指定連結的位置。換句話說, 若執行檔 X 用到 static library A, 而 A 用到 library B。則編 X 時, 要加上 -lA 和 -lB 的參數。編 X 的部份要知道它用到的函式庫有那些相依性, 而不是 A 自己會搞定自己的相依性, 這點不太直覺 (ref.)。
  • static library 只是一堆 object file 的集合體。之所以會用 ar 和 ranlib 編 static library, 目的是減少連結的檔案以方便管理。在用 readelf -Ws 讀 static library 時, 會列出各個 object file 的內容。讀 dynamic library 時就沒這樣列了 (ref.)。
  • 在 Linux 下 linking 時要注意函式庫的順序, 摘錄 gcc manpage 關於 -l 的說明:
    It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o searches library z after file foo.o but before bar.o. If bar.o refers to functions in z, those functions may not be loaded.
  • 當 libm.so 和 libm.a 同時存在時, -lm 會連到 libm.so, 官方說明見 man ld--library=namespec 該段 (ref.)。感謝 cmtsij 的說明。
  • 可用 ldd 找出 dynamic library 實際連到的檔案。

參考資料

4 則留言:

  1. 1. s/objective file/object file/
    2. 列出 ELF .o, .so 或 executable 中的符號,我通常用
    nm X.o
    nm -D /lib/libc.so.6
    輸出中 'T some_func' 代表定義了 some_func (T: text, global text symbol)
    'U some_symb' 代表有用到 some_symb (U: undefined)

    回覆刪除
  2. 1. 已改正
    2. 之前看到 readelf、objdump、nm 都能做到類似的事, 想說有需要再來研究各自的使用時機。這個情境看來用 nm 較方便

    回覆刪除
  3. 更新內文:
    1. 改用 nm 查, 比較好讀
    2. 加上檢查 man page 的步驟

    回覆刪除
  4. These remnants get deposited through the bloodstream to various parts of the body. In the case of marijuana, THC is what most screening tests look for. There are around 80 various metabolites derived from THC, and each has a different effect on the body. Some of these remnants get metabolized and excreted through urine and feces, while some are stored in the fat since THC is a fat-soluble chemical; this increases the interval of time THC stays in your body. The way THC is metabolized also affects how long drug tests can detect THC in saliva, urine, blood, and hair. Thus, metabolites have a certain life cycle for the time they stay detectable to various drug tests. There are four main forms of drug tests with different detection windows that can detect THC. A hair drug test has the largest half-life, and it descends from here in this order: A hair follicle drug test is increasingly gaining ground among employers. It is one of the most difficult tests to pass since it can detect signs of drug consumption even after 90 days of use. Yes, that means those special brownies you had three months ago can still get you in trouble. These are called adulterated specimens that can hide the drugs present in the urine. Although drug testing machines can detect these chemicals and tag your test invalid, the appliances cannot detect chemicals like isopropanol. However, do your research and be cautious before opting for these methods, as these are fraudulent methods and should be avoided as far as possible. Whether it is liquid or powdered synthetic urine, you need to make that fake pee seem real. Whichever brand you choose to use, the product will have detailed instructions for you to follow. However, if you're looking for a quick introduction to know what you're getting into, we have a quick rundown of the whole process.

    回覆刪除

在 Fedora 下裝 id-utils

Fedora 似乎因為執行檔撞名,而沒有提供 id-utils 的套件 ,但這是使用 gj 的必要套件,只好自己編。從官網抓好 tarball ,解開來編譯 (./configure && make)就是了。 但編譯後會遇到錯誤: ./stdio.h:10...