系統將在哪裡搜尋動態庫？

我想知道系統將在哪裡搜尋動態庫。我們以 nxclient 為例。ldd /usr/NX/bin/nxclient 給了我一些輸出，例如

libpng12.so.0 => /usr/NX/lib/libpng12.so.0 (0x00007fcb4a16f000)

現在為什麼系統選擇 /usr/NX/lib/libpng12.so.0 而不是 /usr/lib64/libpng12.so.0？兩者都存在。這是在哪裡配置的？/etc/ld.so.conf* 不包含 /usr/NX 並且我的 $LD_LIBRARY_PATH 是空的。

庫路徑可能在二進製文件中被硬編碼。

來自RPATH 維基百科頁面

GNU C 庫的動態連結器及其衍生的嵌入式 GLIBC 實現了一個相當複雜的算法來搜尋共享庫。基本的搜尋順序是：

1. 二進製文件的 DT_RPATH 動態部分屬性中的（以冒號分隔的）路徑（如果存在）且 DT_RUNPATH 屬性不存在。
2. 環境變數 LD_LIBRARY_PATH 中的（以冒號分隔的）路徑，除非執行檔是 setuid/setgid 二進製文件，在這種情況下它會被忽略。LD_LIBRARY_PATH 可以通過呼叫帶有選項–library-path 的動態連結器來覆蓋（例如/lib/ld-linux.so.2 –library-path $HOME/mylibs myprogram）。
3. 二進製文件的 DT_RUNPATH 動態部分屬性中的（以冒號分隔的）路徑（如果存在）。
4. 基於 ldconfig 記憶體文件（通常位於 /etc/ld.so.cache）進行查找，該文件包含先前在擴充庫路徑（由 /etc/ld.so.conf 設置）中找到的候選庫的編譯列表。但是，如果使用 -z nodeflib 連結器選項鍊接二進製文件，則會跳過預設庫路徑中的庫。
5. 在受信任的預設路徑 /lib 中，然後是 /usr/lib。如果二進製文件是使用 -z nodeflib 連結器選項鍊接的，則跳過此步驟。

查看二進製文件是否配置了 RPATH：

readelf -d 文件名 僅顯示“動態”部分的數據

標題的“動態”部分很有趣，因為它包含在初始載入過程中使用的數據，例如：

NEEDED: libraries needed by this module
RPATH: See “Loader search procedure” below
SONAME: If this module is a library, this item shows the “soname” of the library.

來源：linux 載入器，以及它如何找到庫：ld-linux 等

要查看 ldconfig 記憶體中的所有庫，您可以執行

ldconfig -p

在二進製文件中設置的 RUNPATH 範例

$ readelf -d /opt/teamviewer9/tv_bin/TVGuiSlave.64 | grep -i RUNPATH
0x000000000000001d (RUNPATH)            Library runpath: [${ORIGIN}/../lib]

引用自：https://unix.stackexchange.com/questions/171632