[深度许愿]希望能支持“同时运行不同版本的动态库”

[wwlittewayne]

这应该算是linux系统的一大通病了，如果A和B两个软件依赖某个共同的动态库，但是分别依赖的是两个不同的版本号的，那么linux会阻止程序运行。
这种情况特别是在某些大型EDA软件比较常见，它们往往习惯于自己“魔改”出一份独特的动态库文件，以便适配自己某方面的特殊需求，比如matlab，一旦遇到这类问题会非常让人头疼。
但是windows系统似乎允许不同版本的动态库同时运行，所以从原理上讲，是不是其实有办法避免？个人对操作系统没有深入了解，拍脑袋想：是不是可以直接将不同版本号的同一个动态库，直接当成不同库处理？甚至版本号相同但是内容不同(被魔改了)的，也当成不同库，允许同时运行？(比如用MD5区分)

[Decodetalkers]

你说的是snap还是flatpak还是linglong呢

[wwlittewayne]

不是说这些打包方式，就拿matlab举个例子，它本身一个软件就有二三十个G的大小，没法寄希望于官方额外搞个snap或者flatpak的软件包，但是它又自带了一些魔改后的动态库，所以希望操作系统从底层就直接支持这种情况，直接允许不同版本的库同时运行，而不需要依赖于特定的打包方法

[Decodetalkers]

你可以环境变量，这种我想不出怎么支持法，那只能bash脚本，它本来就是bash拼的，它运行不会有问题

[BLumia]

如果A和B两个软件依赖某个共同的动态库，但是分别依赖的是两个不同的版本号的，那么linux会阻止程序运行。

这个描述不对... 是二进制要求链接的 so 文件相同但所要求的版本不同才会是无法运行。并且也不是 linux 阻止运行，而是 abi 变化导致的符号不匹配问题导致跑不起来。

但是windows系统似乎允许不同版本的动态库同时运行

假设应用仍然找相同的 DLL 的话，Windows 上也会有相同的问题的。Windows 的解决方案就是每个应用自己带自己所要的 DLL（或者选静态链） 而不是共享别的程序的 DLL。这种做法实际上 Linux 上也可以做（很多程序也会这么做，当然这些程序通常是第三方分发的。来自发行版的软件包一般是禁止这么做的）。当然这个其实就是 Windows 上被称为 DLL hell 的事情。

所以这个问题的解决方案一般是...

• 开发者主动附带并加载自己需要的依赖的动态库（或者静态构建），从而避免使用系统提供的 so。或者
• 开发者使用容器技术进行打包（linglong, flatpak, AppImage, snap)，或者
• 用户使用 Nix 之类的方案（实际上 Nix 的方案也比较有意思，有兴趣可以自己了解），或者
• 用户跑 distrobox..?

所以从原理上讲，是不是其实有办法避免？

如果你指的是通过修改“系统”，使开发者、打包者和用户都无感知的方式去避免这种问题，那我觉得不存在这种方案。