※ 引述《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)