※ 引述《littleshan (我要加入劍道社!)》之銘言： : ※ 引述《hermitwhite (不存在的騎士)》之銘言： : : 過了幾年，這次安裝的是Ubuntu，安裝系統時怪毛病變少了，但前 : : 述問題仍然毫不吝嗇地發生。 : Windows 也有同樣的問題啊 : http://en.wikipedia.org/wiki/DLL_hell 既然你把 DLL hell 這件事搬出來 我不曉得你有沒有真正開發過比較大型的專案 說真的，以 DLL hell / shared library hell / jar hell 這種類型的問題 以目前的技術進展而言，還是 Microsoft 的 solution 最為完整 雖然還是無法百分之百解決所有可能的問題 但自 Windows XP SP2 之後，在普通使用者的應用上，以及一般不太刁鑽的專案開發上 DLL hell 的問題發生的機會已經非常非常鮮少!! 但是，Linux 嘛...... 唉，我舉一個我自己遇過很多次的實際案例： 當要開發一個 application A，它需要用到 third party library libB.so 與 libC.so 而 libB.so 與 libC.so 都會用到 libD.so 只不過，libB.so 用的是舊版 libD.so.1，libC.so 用的是新版 libD.so.2 將 library 的相依性畫成下圖： A ↙ ↘ libB.so libC.so ↓ ↓ libD.so.1 libD.so.2 實際 link 完畢後，application A 無法正常運作 要嘛，libD.so.2 的 symbol 會被 libD.so.1 蓋掉 要嘛，libD.so.1 的 symbol 會被 libD.so.2 蓋掉 (端看 link application A 時，-lB 與 -lC 這兩個參數的順序而定) 這是因為，Linux 的 runtime linker 跟本沒有所謂的 symbol namespace 的概念 而這個機制，卻是處理 DLL hell/shared library hell 非常關鍵的一環 所以，當你的程式同時用到新舊版的 shared library 時 裡頭的 symbol 就開始大打架 ---------- 當然，有幾個參考的解法方法 第一種，就是重新 make libB.so，並 link 新版的 libD.so 不過這種方法，若 libD.so 新舊版的 API 差異太大時 重新調整 libB.so 免不了經歷一場腥風血雨 如果 libB.so 本身也是個第三方大型專案的話 搞不好給你兩年的時間，你都不能解決問題 更不用說如果 libB.so 是向另一家公司買來的 closed source library 這個問題就變成無解題 Linux 幾個主要的 distributor，就是要耗掉很多人力 為了就是處理類似的狀況 ---------- 第二種，直接對 run-time linker 開刀 使其支援 symbol namespace 的機制 然後 commit 回 Linux vanilla，造福全世界的 Linux 使用者 ---------- 第三種，也是我所採用的方式 就是自己寫一個 symbol translator，把有衝突的新舊版 shared library 與用到它們的 .o 檔，有衝突的 symbol 都依 shared library 版本加上 prefix 使其不再發生衝突 不過，搞到這種程度，就不要講一般的使用者了 以 RD 而言，大概也倒掉一大半了 ---------- Java 的 jar 也有類似的問題 因為在同一個 class loader 下，class ID 是 global 的 所以不同版本的 jar 檔，裡頭相同的 class 也會打架 不過在 Java 裡頭，要處理這個問題，就比較沒有那麼麻煩 (但還是有點麻煩) 既然 libB.jar 用到舊版的 libD.jar libC.jar 用到新版的 libD.jar 這時，就準備兩個 class loader libB.jar 裡頭的 class，就放在 class loader B 中 (舊版的 libD.jar 也會自動一併放入 class loader B) libC.jar 裡頭的 class，就放在 class loader C 中 (新版的 libD.jar 也會自動一併放入 class loader C) (比如像 Tomcat 這類的 servlet container 就是以類似的方式處理這個問題) 這時就可以避掉某些等級的 jar hell 的問題 ---------- 在 Windows 平台下，這個問題就好處理多了 只要不要用到太刁鑽的狀況，上述的狀況都不是問題 我只能這麼說，至少，Microsoft 在這個問題上面，有真真正正下過苦功處理 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.32.58.129 ※ 編輯: mgtsai 來自: 114.32.58.129 (01/22 22:17)