查詢程式載入的動態庫的路徑
事件的起因：
最近編譯gtk版的webkit後發現，他需要指令碼Tools/Scripts/run-launcher來啟動WebKitBuild/Debug/Programs的GtkLauncher、MiniBrowser等
如果正常執行會發生出下異常
[email protected]:~/study/webkit/webkit_nightly/WebKit-r150880/WebKitBuild/Debug/Programs$ ./GtkLauncher ./GtkLauncher: error while loading shared libraries: libgstreamer-1.0.so.0: cannot open shared object file: No such file or directory
想搞清楚與做到的事：
１）為什麼需要指令碼來啟動，直接執行會出現動態庫載入異常，即為什麼動態庫搜尋不到；
２）如果直接在Programs執行GtkLauncher等需要做那些工作；
分析與解決問題；
１）根據異常資訊，是動態庫載入不到，另外加上之前發現到目前webkit gtk的編譯與之前有所不同，最大的區別在於編譯需要的依賴庫是實時編譯的，即一定在編譯目錄下的某個子目錄存放著依賴的動態庫，然後通過執行指令碼來啟動的過程中應該是為作某些工作，讓GtkLauncher等能找到需要的動態庫；
２）由第一步的分析，到編譯目錄下搜尋.so檔案，發現WebKitBuild/Dependencies/Root/lib64/下存放著n多動態庫，如下
cairo libcairo-script-interpreter.so.2.11200.8 libgio-2.0.so libgstbasevideo-1.0.so.0.7.0 libgstriff-1.0.so.0 libharfbuzz.so gdk-pixbuf-2.0 libcairo.so libgio-2.0.so.0 libgstcheck-1.0.so libgstriff-1.0.so.0.7.0 libharfbuzz.so.0 gio libcairo.so.2 libgio-2.0.so.0.3600.0 libgstcheck-1.0.so.0 libgstrtp-1.0.so libharfbuzz.so.0.914.0 girepository-1.0 libcairo.so.2.11200.8 libglib-2.0.so libgstcheck-1.0.so.0.7.0 libgstrtp-1.0.so.0 libpixman-1.a glib-2.0 libffi-3.0.10 libglib-2.0.so.0 libgstcodecparsers-1.0.so libgstrtp-1.0.so.0.7.0 libpixman-1.so gnome-settings-daemon-3.0 libffi.a libglib-2.0.so.0.3600.0 libgstcodecparsers-1.0.so.0 libgstrtsp-1.0.so libpixman-1.so.0 gstreamer-1.0 libffi.so libgmodule-2.0.so libgstcodecparsers-1.0.so.0.7.0 libgstrtsp-1.0.so.0 libpixman-1.so.0.24.0 gtk-2.0 libffi.so.5 libgmodule-2.0.so.0 libgstcontroller-1.0.so libgstrtsp-1.0.so.0.7.0 librsvg-2.a gtk-3.0 libffi.so.5.0.10 libgmodule-2.0.so.0.3600.0 libgstcontroller-1.0.so.0 libgstsdp-1.0.so librsvg-2.so libatk-1.0.so libfontconfig.a libgobject-2.0.so libgstcontroller-1.0.so.0.7.0 libgstsdp-1.0.so.0 librsvg-2.so.2 libatk-1.0.so.0 libfontconfig.so libgobject-2.0.so.0 libgstfft-1.0.so libgstsdp-1.0.so.0.7.0 librsvg-2.so.2.36.1 libatk-1.0.so.0.20809.1 libfontconfig.so.1 libgobject-2.0.so.0.3600.0 libgstfft-1.0.so.0 libgstsignalprocessor-1.0.so libsoup-2.4.a libatk-bridge-2.0.so libfontconfig.so.1.4.4 libgstapp-1.0.so libgstfft-1.0.so.0.7.0 libgstsignalprocessor-1.0.so.0 libsoup-2.4.so libatk-bridge-2.0.so.0 libfreetype.a libgstapp-1.0.so.0 libgstnet-1.0.so libgstsignalprocessor-1.0.so.0.7.0 libsoup-2.4.so.1 libatk-bridge-2.0.so.0.0.0 libfreetype.so libgstapp-1.0.so.0.7.0 libgstnet-1.0.so.0 libgsttag-1.0.so libsoup-2.4.so.1.6.0 libatspi.so libfreetype.so.6 libgstaudio-1.0.so libgstnet-1.0.so.0.7.0 libgsttag-1.0.so.0 libxml2.a libatspi.so.0 libfreetype.so.6.10.0 libgstaudio-1.0.so.0 libgstpbutils-1.0.so libgsttag-1.0.so.0.7.0 libxml2.so libatspi.so.0.0.1 libgailutil-3.so libgstaudio-1.0.so.0.7.0 libgstpbutils-1.0.so.0 libgstvideo-1.0.so libxml2.so.2 libcairo.a libgailutil-3.so.0 libgstbase-1.0.so libgstpbutils-1.0.so.0.7.0 libgstvideo-1.0.so.0 libxml2.so.2.9.0 libcairo-gobject.a libgailutil-3.so.0.0.0 libgstbase-1.0.so.0 libgstphotography-1.0.so libgstvideo-1.0.so.0.7.0 pkgconfig libcairo-gobject.so libgdk-3.so libgstbase-1.0.so.0.7.0 libgstphotography-1.0.so.0 libgthread-2.0.so python2.7 libcairo-gobject.so.2 libgdk-3.so.0 libgstbasecamerabinsrc-1.0.so libgstphotography-1.0.so.0.7.0 libgthread-2.0.so.0 xml2Conf.sh libcairo-gobject.so.2.11200.8 libgdk-3.so.0.600.0 libgstbasecamerabinsrc-1.0.so.0 libgstreamer-1.0.so libgthread-2.0.so.0.3600.0 xorg libcairo-script-interpreter.a libgdk_pixbuf-2.0.so libgstbasecamerabinsrc-1.0.so.0.7.0 libgstreamer-1.0.so.0 libgtk-3.so libcairo-script-interpreter.so libgdk_pixbuf-2.0.so.0 libgstbasevideo-1.0.so libgstreamer-1.0.so.0.7.0 libgtk-3.so.0 libcairo-script-interpreter.so.2 libgdk_pixbuf-2.0.so.0.2600.5 libgstbasevideo-1.0.so.0 libgstriff-1.0.so libgtk-3.so.0.600.0
３）需要驗證與核實，用指令碼啟動GtkLauncher然後檢視程式所載入的動態庫的路徑(google了一下，找到lsof這個命令)
[email protected]:~/study/webkit/webkit_nightly/WebKit-r150880$ ./Tools/Scripts/run-launcher --gtk --debug &
[1] 9825
[email protected]:~/study/webkit/webkit_nightly/WebKit-r150880$ Starting webkit launcher.
Gtk-Message: Failed to load module "canberra-gtk-module"
[email protected]:~/study/webkit/webkit_nightly/WebKit-r150880$ lsof -p 9825 | grep libgstreamer
GtkLaunch 9825 luogw mem REG 8,8 4311120 18000138 /home/luogw/study/webkit/webkit_nightly/WebKit-r150880/WebKitBuild/Dependencies/Root/lib64/libgstreamer-1.0.so.0.4.0
4）通過上述分析只要讓GtkLauncher正常的載入到lib64下的動態庫就不需要啟動指令碼來執行（還沒搞清楚run-launcher是怎麼做到的）
google學習了linux下程式搜尋動態庫的知識，現學現用，發現設置LD_LIBRARY_PATH是一種解決方案(記得要export下變數)
相關推薦
查詢程式載入的動態庫的路徑
事件的起因： 最近編譯gtk版的webkit後發現，他需要指令碼Tools/Scripts/run-launcher來啟動WebKitBuild/Debug/Programs的GtkLauncher、MiniBrowser等 如果正常執行會發生出下異常 [email
如何將程式的執行檔案和靜態載入動態庫放在不同的目錄
一般windows程式的exe和dll需要放在同一個目錄，靜態載入才不會報錯，否則需要修改path環境變數，將所有沒有和exe放在同一目錄的dll的路徑加在path環境變數中。 有沒有一種方法不去手動修改path環境變數並且可以將exe和dll隨心所欲的改變路徑呢？我沒有發
關於程式執行時載入動態庫失敗的解決方法
一般我們在Linux下執行某些外部程式的時候可能會提示找不到共享庫的錯誤, 比如: error while loading shared libraries: libevent-1.4.so.2: cannot open shared object file: No such file or direc
Linux下修改使用者bashrc新增自定義路徑來載入動態庫
有時候，我們在Linux下編寫的程式使用了第三方動態庫，如果當我們把程式移植到別的機器上，需要把動態庫一起移植。但是如果我們沒有系統許可權的話，就無法把動態庫放到系統目錄，從而我們的程式無法正確連結到該檔案，導致無法執行。這時，我們可以通過修改使用者目錄下的.bashrc檔
Windows平臺LoadLibrary載入動態庫搜尋路徑的問題
一、背景 在給Adobe Premiere/After Effects等後期製作軟體開發第三方外掛的時候，我們總希望外掛依賴的動態庫能夠脫離外掛的位置，單獨儲存到另外一個地方。這樣一方面可以與其他程式共享這些動態庫，還能保證外掛安裝時非常的清爽。就Adobe Premiere Pro/After Effec
沒有載入動態庫導致的error: symbol lookup error: undefined symbol
做了一個瀏覽器外掛，需要編譯為 abcPlugins.so ， 這個.so需要呼叫另外一個業務庫 defLib.so裡面的函式。 把abcPlugins.so替換到目標板上，瀏覽器程序啟動不起來。 1. 查詢瀏覽器程序啟動過程錯誤 1
C++載入動態庫的形式來實現封裝
目錄結構 └── test ├── CMakeLists.txt ├── base.h //設定介面 ├── drive.cpp //具體實現 └── main.cpp
linux 程式、動態庫、靜態庫內部新增版本號和編譯時間
給程式和庫新增版本號和庫，有利於維護和升級。 當然你可以在檔名上體現，比如有個程式叫 yun，檔名寫為 yun_1.0.2，但這個需要每次手動維護，而且不能100%確保當前程式就是那個版本。所以，把版本號體現在程式內部，是一個不錯的選擇。 --------------------------
OSX10.9 QT5.3.1 關於載入動態庫（Cannot load library.....)
在LINUX 、WINDOWS程式正常，但在MAC下卻不能載入。如下圖 在生成的APP檔案，右鍵‘顯示包內容’ 位定到 fnd_main.app/Contents/MacOS，把生成的動態庫 *.dblib複製進去。 ASSERT: "uint(i) <
動態庫路徑配置- /etc/ld.so.conf檔案
Linux 系統上有兩類根本不同的 Linux 可執行程式。第一類是靜態連結的可執行程式。靜態可執行程式包含執行所需的所有函式 — 換句話說，它們是“完整的”。因為這一原因，靜態可執行程式不依賴任何外部庫就可以執行。 第二類是動態連結的可執行程式。 靜態可執行程式與動態可執行程式比較
linux設定動態庫路徑和環境變數
linux安裝原始碼編譯出來的庫後，如何讓系統預設識別到， 如編譯後安裝在/usr/local/aarch64-qt下 1、設定動態庫連結配置 如果不設定動態庫連線，系統就找不到需要的*.so，導致軟體執行失敗。 可以ldd一下，如： [email protected]:~$ ldd
更改PE檔案載入動態庫
最近看了《逆向工程核心原理》，其中第25.4節講了更改PE檔案讓目標檔案載入我們的動態庫。現在做一下完整介紹。 PE檔案的匯入DLL資訊儲存在IDT中，於是我們只需將DLL加到目標PE檔案的IDT中，這時我們得先看一下IDT的空間大小。 1.檢視IDT: 首先用PEVie
/etc/ld.so.conf詳解 及 編譯尋找動態庫路徑解析
轉自 http://www.cnblogs.com/chris-cp/p/3591306.html /etc/ld.so.conf 此檔案記錄了編譯時使用的動態庫的路徑，也就是載入so庫的路徑。 預設情況下，編譯器只會使用/lib和/usr/lib這兩個目錄下的
C++批量載入動態庫函式方法
1、列舉定義enum { // 0 - GigE DLL (implicitly called) Func_isVersionCompliantDLL, Func_isDriverAv
動態庫載入動態庫使用gflags的方法
最近做的專案，一個module需要載入多個外掛，外掛是用dlopen的方式載入的。module中使用一些gflags，而外掛中也需要使用gflags。 在module啟動時執行ParseCommandLineFlags，之後在載入外掛，讀取/proc/self/comman
cocos2dx android ndk 載入動態庫(.so)
當專案開發到一定階段，基本上需要接入第三方sdk的了，ios上還比較好辦，就不說了。android上步驟是比較繁瑣的。通常sdk會叫你把動態庫檔案扔到專案的libs中，但Cocos2dx在編譯時會把libs目錄下的東西清空，然後從其他地方引入的，所以不能直接放進去。關於pr
LoadLibrary載入動態庫失敗的解決辦法
方式一 採用LoadLibraryEx 若DLL不在呼叫方的同一目錄下，可以用LoadLibrary(L"DLL絕對路徑")載入。但若呼叫的DLL內部又呼叫另外一個DLL，此時呼叫仍會失敗。解決辦法是用LoadLibraryEx： LoadLibraryEx("DLL絕對
linux 設定執行時動態庫路徑
export LD_LIBRARY_PATH="/mnt/pub/libs/share:$LD_LIBRARY_PATH" PATH和LD_LIBRARY_PATH本質都是變數，所謂變數的意思就是由別人賦值產生的，直覺往往會讓我們新增和減少這個變數本身的某些路徑
linux中動態載入動態庫的方法
dlopen()是一個強大的庫函式。該函式將開啟一個新庫，並把它裝入記憶體。該函式主要用來載入庫中的符號，這些符號在編譯的時候是不知道的。比如 Apache Web 伺服器利用這個函式在執行過程中載入模組，這為它提供了額外的能力。一個配置檔案控制了載入模組的過程。這種機制使得在系統中新增或者刪除一個模組
載入動態庫失敗的原因分析
載入動態庫有幾方面的原因。歸納如下： 1） 動態庫路徑錯誤。 2） 動態庫依賴缺失。這個可以利用depends工具看下依賴情況。如果缺失，請尋找相應庫，然後把相應庫放在程式同一目錄下，或者放在system32目錄下。 3） 依賴動態庫本身有問題。這個最難定位。有的時候，依賴