※ 引述《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)
推
01/22 23:03, , 1F
01/22 23:03, 1F
推
01/23 03:10, , 2F
01/23 03:10, 2F
推
01/23 17:59, , 3F
01/23 17:59, 3F
→
01/23 18:00, , 4F
01/23 18:00, 4F
推
01/25 23:40, , 5F
01/25 23:40, 5F
討論串 (同標題文章)