Linux 動態庫加載機制深度解析：從加載順序問題到 LD_PRELOAD 解決方案

即使將庫文件重命名為 libmyglib.so 並用 -lmyglib 鏈接，生成的可執行文件內部仍記錄原 SONAME libglib-2.0.so.0，運行時依然尋找系統庫。

Linux 動態庫搜索順序

1. 可執行文件內 DT_RPATH（已棄用）
2. 環境變量 LD_LIBRARY_PATH
3. 可執行文件內 DT_RUNPATH
4. /etc/ld.so.cache 緩存
5. 預設系統路徑 /lib、/usr/lib

LD_LIBRARY_PATH 優先級雖高，但若系統庫在 ld.so.cache 中且同名，某些情況下仍可能優先被找到（視具體 ld-linux.so 實現）。

解決方案對比

方案一：LD_PRELOAD 強制優先加載（推薦，非侵入式）

export LD_PRELOAD=./libglib-2.0.so.0:./libgmodule-2.0.so.0
./test

LD_PRELOAD 指定的庫最優先加載，符號解析時優先使用，完美覆蓋系統庫。ldd 輸出將顯示本地庫路徑。

方案二：修改系統庫（不推薦，風險高）

• 2.1 升級安裝覆蓋：包管理器安裝新版，最乾淨但可能破壞依賴舊版的其他程式。
• 2.2 直接替換 .so 文件或修改軟鏈接：cp libglib-2.0.so.0.2800.8 /lib64/，極易遺留垃圾、引發版本衝突。
• 2.3 ldconfig 註冊自定義路徑：sudo ldconfig /opt/glib-2.28.8/lib，將路徑加入系統緩存，影響全局。

方案三：編譯時嵌入 RPATH/RUNPATH（工程化最佳實踐）

gcc -Wl,-rpath='$ORIGIN/../lib' -L./lib -lglib-2.0 -o test test.c

$ORIGIN 表示可執行文件所在目錄，部署時將 lib/ 與可執行文件同級放置，無需環境變量，遷移性最佳。

調試利器：LD_DEBUG

LD_DEBUG=libs ./test        # 顯示庫搜索過程
LD_DEBUG=symbols ./test     # 顯示符號解析過程
LD_DEBUG=help ./test        # 查看所有調試選項

補充知識：nm 查看導出符號

nm -Du /lib64/libglib-2.0.so.0  # 列出動態符號表（未定義+導出）

總結