在利用源**進行軟體編譯的過程中，經常會出現以下錯誤：
#include <>直接到系統指定的某些目錄中去找某些標頭檔案。那麼gcc如何確定標頭檔案搜尋路徑呢？#include 「」先到原始檔所在資料夾去找，然後再到系統指定的某些目錄中去找某些標頭檔案。
q:檔案路徑有多種，那麼先後順序如何？
-i 指定的路徑
gcc 環境變數指定的路徑c_include_path, cplus_include_path, objc_include_path上述指定目錄/usr/includeq:openssl/rsa.h: no such file or directory
這種錯誤，是缺少相關標頭檔案導致的，通常情況下，執行apt-get install libopenssl-dev即可解決（缺少其他標頭檔案同理）。
眾所周知，linux動態庫的預設搜尋路徑是/lib和/usr/lib。動態庫被建立後，一般都複製到這兩個目錄中。當程式執行時需要某動態庫， 並且該動態庫還未載入到記憶體中，則系統會自動到這兩個預設搜尋路徑中去查詢相應的動態庫檔案，然後載入該檔案到記憶體中。linux除了預設的搜尋路徑之外，還通過以下三種方法指定：
配置檔案/etc/ld.so.conf (編輯之後，需要執行命令ldconf來使得更改生效)
通過環境變數ld_library_path指定動態庫搜尋路徑。
編譯目標**時，指定動態搜尋路徑-wl,-rpath
以上，我們一共有5個路徑指定方式，它們的先後順序是：編譯時指定 > 環境變數 > 配置檔案 > 預設路徑
tips
q:共享庫如何命名？
在linux系統中，共享庫的命名方式是libname.so.
q:librte_eal.a(eal.o): undefined reference to symbol 『pthread_create@@glibc_2.2.5』 /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: dso missing from command line)
這個問題比較特殊，ld找不到對應symbol不是由於對應so不在路徑中，而是dso missing from command line.
解決方法：鏈結階段，指定使用的動態庫:-lpthread
q:為何需要顯式指定某個動態鏈結庫？
解答：從ubuntu11.04之後，ld的機制發生了變化。對於這樣的場景：
function spin: included in libwheel;在原來，pro是直接可以引用spin函式——即使它並沒有use libwheel；但是這裡有乙個潛在的風險：一旦libcar不再use libwheel，這個依賴的傳遞性就會被打破，如此將產生鏈結錯誤。所以，libcar used libwheel;
program pro used libcar;
ld now runs with the --no-copy-dt-needed-entries option enabled by default.。必須顯式指定動態鏈結的函式所在的庫。
詳細解釋可以參考(
gcc指定標頭檔案路徑及動態鏈結庫路徑
include 直接到系統指定的某些目錄中去找某些標頭檔案。include 先到原始檔所在資料夾去找，然後再到系統指定的某些目錄中去找某些標頭檔案。1.會在預設情況下指定到 usr include資料夾 更深層次的是乙個相對路徑，gcc可執行程式的路徑是 usr bin gcc，那麼它在實際工作時指...
gcc指定標頭檔案搜尋路徑及動態鏈結庫搜尋路徑
include 直接到系統指定的某些目錄中去找某些標頭檔案。include 先到原始檔所在資料夾去找，然後再到系統指定的某些目錄中去找某些標頭檔案。1.會在預設情況下指定到 usr include資料夾 更深層次的是乙個相對路徑，gcc可執行程式的路徑是 usr bin gcc，那麼它在實際工作時指...
使用gcc時標頭檔案路徑和動態鏈結庫路徑
在使用gcc編譯連線生成可執行檔案時，經常會碰到變數未定義 鏈結時或者執行可執行檔案時找不到相應的動態庫等問題，本文首先介紹了gcc在編譯時標頭檔案路徑相關選項以及搜尋路徑順序，然後討論了編譯成可執行檔案時動態庫的搜尋路徑順序，最後說明了生成可執行檔案後，執行檔案時動態庫的搜尋路徑順序。搞清楚這三個...