參考了不少資料，其中最靠譜是這個：http://www.mingw.org/wiki/librarypathhowto

和http://www.kaizou.org/2015/01/linux-libraries/

經過線上實際驗證，GCC編譯、連結、執行時庫查詢順序如下，這個順序真實可信，網上很多說法有些地方都是有些問題的，

導致遇到問題時總是不確定到底是哪裡出了問題，花了不少時間，絕知此事要躬行。

略微讓人頭疼的是，沒有找到官方文件清晰說明什麼情況下該如何查詢依賴庫目錄，連結時查詢直接依賴庫和間接依賴庫的方式

差別挺大。。。

一、概括GCC連結時搜尋直接依賴庫的先後順序：

1、LDFLAGS選項 -L 引數指定的路徑。
2、系統環境變數 LIBRARY_PATH（某些系統或編譯器下可能無效）。
3、gcc安裝時自身配置的搜尋路徑，gcc --print-search-dir | grep libraries 可檢視，

一般會包含該版本gcc必需的庫而不一定包含當前系統庫路徑，連結時會以-L引數形式傳遞給ld。

4、ld安裝時自身配置的搜尋路徑，ld -verbose | grep SEARCH_DIR 可檢視，

gcc通過呼叫collect2工具呼叫ld。

To summarize, when linking an executable against a static library, you need to specify explicitly all dependencies towards shared libraries introduced by the static library on the link command.

二、概括GCC鏈接時搜索間接依賴庫（直接依賴庫的依賴庫）的先後順序：（即secondary dependencies）

特別說明：搜尋直接依賴庫的連結查詢順序同樣適用於編譯生成動態的（ shared）、可重定位（relocatable）目標的情形。

特別說明：本條目所列連結順序僅適用於編譯生成非動態的（ non-shared）、非可重定位（non-relocatable）目標的情形，比如生成二進位制可執行程式，ld手冊中有明確說明，是否適合其它情形不確定。在此種情形下，查詢一個依賴庫自身的依賴庫時，-L引數指定的搜尋目錄無效（至少某些情況下是如此），這不同於連結一個二進位制時查詢直接依賴目錄的順序。（1） 參考linux man手冊 ld說明：https://linux.die.net/man/1/ld  “-rpath-link=dir”章節（2）參考同樣問題的分析：http://www.kaizou.org/2015/01/linux-libraries/連結時對於依賴庫中依賴的搜尋順序如下(摘自ld手冊)：

-rpath-link=dir

When using ELF or SunOS, one shared library may require another. This happens when an "ld -shared" link includes a shared library as one of the input files.

When the linker encounters such a dependency when doing a non-shared, non-relocatable link, it will automatically try to locate the required shared library and include it in the link, if it is not included explicitly. In such a case, the -rpath-link option specifies the first set of directories to search. The -rpath-link option may specify a sequence of directory names either by specifying a list of names separated by colons, or by appearing multiple times.

This option should be used with caution as it overrides the search path that may have been hard compiled into a shared library. In such a case it is possible to use unintentionally a different search path than the runtime linker would do.

The linker uses the following search paths to locate required shared libraries:

(1)  Any directories specified by -rpath-link options.

(2) Any directories specified by -rpath options. The difference between -rpath and -rpath-link is that directories specified by -rpath options are included in the executable and used at runtime, whereas the -rpath-link option is only effective at link time. Searching -rpath in this way is only supported by native linkers and cross linkers which have been configured with the --with-sysroot option.

(3) On an ELF system, for native linkers, if the -rpath and -rpath-link options were not used, search the contents of the environment variable "LD_RUN_PATH".

(4) On SunOS, if the -rpath option was not used, search any directories specified using -L options.

(5) For a native linker, the search the contents of the environment variable "LD_LIBRARY_PATH".

(6) For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of a shared library are searched for shared libraries needed by it. The "DT_RPATH" entries are ignored if "DT_RUNPATH"entries exist.

(7) The default directories, normally /lib and /usr/lib.(這裡應該是指 ld -verbose | grep SEARCH_DIR顯示的搜尋目錄)

(8) For a native linker on an ELF system, if the file /etc/ld.so.conf exists, the list of directories found in that file.

If the required shared library is not found, the linker will issue a warning and continue with the link.

“Ok, this is not crystal-clear, but what it actually means is that when specifying the path for a secondary dependency, you should not use -L but -rpath-link

To summarize, when linking an executable against:

• a static library, you need to specify all dependencies towards other shared libraries this static library depends on explicitly on the link command.

• a shared library, you don’t need to specify dependencies towards other shared libraries this shared library depends on, but you may need to specify the path to these libraries on the link command using the -rpath/-rpath-link options.

Note however that expressing, discovering and adding implicit libraries dependencies is typically a feature of your build system (autotools, cmake), as demonstrated in my samples.”

二、概括GCC執行時庫的搜尋庫先後順序：
1、程式自身的RPATH（Library rpath）， readelf -d bin可檢視，在連結時通過-rpath引數寫入程式ELF結構資訊中，而傳入連結器中預設的-rpath引數是來自安裝gcc時配置的檔案specs（其中的配置項linker）。
2、編譯時LDFLAGS選項 -L 引數指定的路徑。
3、系統環境變數LD_LIBRARY_PATH。
4、在 /etc/ld.so.conf.d/ 目錄下的配置檔案指定的動態庫絕對路徑（通過ldconfig生效，一般是非root使用者時使用）。
5、gcc安裝時自身配置的搜尋路徑，gcc --print-search-dir | grep libraries 可檢視，一般會包含該版本gcc必需的庫而不一定包含當前系統庫路徑。三、補充說明：
1、在連結和執行查詢庫的過程中，只要找到同名的庫則不管該庫是否相容均停止查詢，即便相容的庫可能出現在靠後的搜尋路徑中。
2、安裝高版本gcc時一般是直接解壓已經編譯好的gcc，然後直接複製一份至新的路徑下，bcloud就是這麼做的，可能是為了便於恢復編譯環境吧。
3、如果系統自帶的是低版本gcc，而需要使用高版本gcc編譯程式，如果該程式依賴了非系統庫（低版本gcc編譯），如果這個非系統庫的安裝目錄下恰好有和高版本gcc依賴的庫同名的庫，那麼為了能夠使用這個非系統庫，這時高版本gcc編譯時很可能會出現問題，必需保證連結器在查詢庫時，查詢高版本gcc自身庫一定要先於任意系統庫（或任意庫）所在的目錄。原因是高版本gcc應該是改進了相當一部分系統庫，和當前低版本系統庫並不相容，而對於相容的那些庫，高版本gcc庫可以直接使用當前系統庫。 

• You can pass the -v option to gcc so that it shows you how it invokes the linker. In fact, it normally does not invoke ld directly, but indirectly via a tool called collect2 (which lives in one of its internal directories), which in turn invokes ld. That will show you what -L options are being used.

• You can add -Wl,--verbose to the gcc options to make it pass --verbose through to the linker, to see the linker script as described above.

四、庫版本號

  如果 major version number不一致，說明庫的ABI介面是不相容的，不同major version 庫之間不能相互引用或依賴，相同major version一般是可以相互引用和依賴的，但工作時具體行為是否正確需要進一步驗證。

  Linux上的shared library有三個名字，分別是：

• 共享庫本身的檔名（real name)

  其通常包含完整的版本號，比如：libmath.so.1.1.1234 。lib是Linux庫的約定字首，math是共享庫名字，so是共享庫的字尾名，1.1.1234的是共享庫的版本號，由主版本號+小版本號+build號組成。主版本號，代表當前動態庫的版本，如果共享庫的介面發生變化，那麼這個版本號就要加1；後面的兩個版本號（小版本號和 build號）是用來指示庫的更新迭代號，表示在介面沒有改變的情況下，由於需求發生變化等因素，開發的新程式碼。

• 共享庫的soname（Short for shared object name）

  用來告訴應用程式，在載入共享庫的時候，應該使用的檔名。其格式為lib + math + .so + (major version number) 其只包含主版本號，換句話說，也就是隻要共享庫的介面沒有變，soname就能與real name保持一致，因為主版本號一樣。所以在庫的real name的小版本號和 build號發生改變時，應用程式仍然可以通過soname得知，要使用的是哪個real name。

• 共享庫的連結名（link name）

  是專門為應用程式在編譯時的連結階段而用的名字。這個名字就是lib + math +.so ,比如libmath.so。其是不帶任何版本資訊的。在共享庫的編譯過程中，編譯器將生成一個共享庫及real name，同時將共享庫的soname寫在共享庫檔案裡的檔案頭裡面。可以用命令readelf -d sharelibrary | grep soname檢視。 在應用程式引用共享庫時，連結選項裡面用的是共享庫的link name。通過link名字找到對應的real name動態庫，並且把其中的soname提取出來，寫在應用程式自己的檔案頭的共享庫欄位裡面。當應用程式執行時，就會通過soname，結合動態連結程式（ld.so），在給定的路徑下載入real name的共享庫。

以上。