2011-11-01 53 views
17

本頁面 - http://labs.qt.nokia.com/2011/10/28/rpath-and-runpath/ - 說,大約爲了在ld.so庫搜索:使用RPATH而不是RUNPATH?

Unless loading object has RUNPATH: 
    RPATH of the loading object, 
     then the RPATH of its loader (unless it has a RUNPATH), ..., 
     until the end of the chain, which is either the executable 
     or an object loaded by dlopen 
    Unless executable has RUNPATH: 
     RPATH of the executable 
LD_LIBRARY_PATH 
RUNPATH of the loading object 
ld.so.cache 
default dirs 

,然後建議:

當你船的二進制文件,或者使用RPATH,而不是運行路徑或保證 LD_LIBRARY_PATH在它們運行之前被設置。

因此,使用RPATHRUNPATH是不好的,因爲RUNPATH樣-的取消預期RPATH所以間接動態加載不起作用?但爲什麼然後RPATH已棄用RUNPATH

有人可以解釋一下情況嗎?

回答

13

當您發佈一個二進制文件時,最好爲用戶提供一種方法來調整二進制文件以適應他們自己系統的具體情況,尤其是調整庫搜索路徑。

用戶一般可以調整LD_LIBRARY_PATH/etc/ld.co.conf,這兩者都與優先級低於DT_RPATH,即不能覆蓋什麼是在二進制硬編碼的,而如果你使用DT_RUNPATH代替,用戶可與LD_LIBRARY_PATH覆蓋它。 (FWIW,我認爲ld.so.conf也應該優先於DT_RUNPATH,但無論如何,至少我們已經得到了LD_LIBRARY_PATH)。

此外,我強烈不同意上面使用DT_RPATH的建議。國際海事組織,它最好在運輸的二進制文件中使用暗號DT_RPATH而不是DT_RUNPATH

除非

你船與您的可執行所有的依賴庫,並希望確保事情JustWork(TM)安裝後,在這種情況下使用DT_RPATH

+1

問題是,建議使用RUNPATH而不使用RPATH,並且不推薦使用RPATH,但RUNPATH目前不受所有系統支持。所以我今天做了什麼**來使申請工作?正如Qt文章所示,在使用插件時,使用RPATH比RUNPATH更有用。所以整個情況在這裏非常混亂 – zaharpopov

+1

@zaharpopov,我推薦並遵循自己的最佳方法是生成很好地集成在目標平臺中的應用程序,其中包括*不分發競爭版本的平臺共享庫*。我認爲這是問題的根源,並且在'DT_RPATH'和'DT_RPATH'之間進行了黑客攻擊和破解,而朋友是一個試圖側重解決問題而不是解決問題的錯誤嘗試。 – chill

+1

這不簡單。與Qt問題是該應用程序想要Qt庫的更新版本比系統上存在。有些系統已經過時了Qt SO,那麼你會怎麼做?如果你需要一個特定的版本 – zaharpopov

10

奇爾的回答是完全正確的;我想簡單地添加一些顏色,從最近讀取glibc源文件([master 8b0ccb2],2.17)。清楚的是,如果在給定級別指定的位置沒有找到庫,則嘗試下一級。如果在給定級別找到了庫,搜索將停止。

動態庫搜索順序:

  1. DT_RPATH在ELF二進制,除非DT_RUNPATH集。
  2. LD_LIBRARY_PATH條目,除非的setuid/setgid的
  3. DT_RUNPATH在ELF二進制
  4. /etc/ld.so.cache中條目,除非-z nodeflib在鏈接時給定
  5. /lib下,/ usr/lib中除非 - z nodeflib
  6. 完成,「未找到」。
4

但是,爲什麼那麼RPATH得到了贊成RUNPATH的過時?

當引入DT_RPATH時,它優先於所有其他參數。 即使爲了開發目的,這也無法覆蓋庫搜索路徑。 因此引入了另一個參數LD_RUNPATH,其優先級低於LD_LIBRARY_PATH。

更多細節可在"How to write shared libraries"作品Ulrich Drepper

+1

這個答案解釋了對'DT_RUNPATH'的需求,但不解釋爲什麼'DT_RPATH'已被棄用。兩者都有自己的用法,當使用'LD_LIBRARY_PATH'時,'DT_RUNPATH'會中斷'libtool':https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732 – vinc17