为什么如今的库还会被编译成 shared library 来用？内存和磁盘空间都已经足够了呀

[fhc023]

主要是历史原因吗？是不是还有其他的理由？

[hilbertz]

确实没有太大意义，共享库主要是为了商业分发

[lcdtyph]

@littlewing 还是解决了一些内存问题的吧？

[XIVN1987]

python 可以很方便的调用 C/C++编写的 dll 库，，如果是静态连接库的话，，必须得装 C/C++编译器才能使用，，

[RqPS6rhmP3Nyn3Tm]

想起了被 glibc 支配的恐惧

[w01230]

够用了也别浪费呀， 也有成本问题， ……看看 OPENWRT 的路由器~

[ysc3839]

@iwtbauh
Windows 没有共享库版本控制，那么应用需要用的库不都是自己打包吗？再怎么升级也不会影响到别的软件呀？
你可能会说 VC++ 运行库是共享的，但是 VC++ 本身不同版本是分开的，文件名中就包含有主版本号，同一个主版本要保证兼容的。

你说 Unix 共享库版本控制做的非常好，本质不是 Unix 做得好，而是大多数类 Unix 系统有包管理，通过包管理能很好地做到版本控制。像 macOS 这种没有自带包管理的系统，也是像 Windows 这样软件需要什么就自己打包的。

[janxin]

编译快算不算优点？

[est]

@iwtbauh dll 地狱早就被 winsxs 解决了。win98 时代说这个还有道理，现在说就是老黄历了。

linux 下不同 distro、甚至同一 distro 不同版本 之间根本谈不上 .so 兼容。那种加版本的 trick 就不要拿出来 show 了。

[fhc023]

@iwtbauh 我觉得是有道理的 但是 linux 上的版本问题就算被解决了 但是还是感觉很奇怪 因为如果上层都各自用各自的版本了，那干嘛还要 shared library。 反而为了解决这些版本问题增加了复杂度 感觉不值得。不过像 @w01230 说的这种内存特别紧缺的是很有用的。而且还有像 glibc 这种不知道是有历史包袱还是故意为之的情况存在。所以我觉得看情况，像我能用 static 的时候就尽量用 static。虽然最终出来的 executable 里还是有 so 只要解决了生产环境的兼容问题 我就能接受了。

[fhc023]

感觉学到了很多哈 谢谢大家 如果大家有各种奇妙的关于这问题的链接都可以 po 出来

[est]

@fhc023 尽量 static 有一个特别的坑。就是遇到大规模安全事故需要普遍升级的时候

那个时候你就哭吧。2333

[behanga]

当你吐槽 XXX 这破 app 都 100/200 多 MB 的时候 有可能里面的 so 就没用 shared library

[IdontWanToBeBan]

随意用这不好吗。。

[iwtbauh]

@ysc3839 #46

你怕是不知道以前很多应用程序安装时直接升级（降级）系统库。

而且这种行为的应用程序到现在也是存在的。

@est #48

这个问题和 distro 之间不兼容没有半点关系。

所以说我说是“现在为了保证前向兼容采用了一种极其丑陋的方法规避问题”啊。

@fhc023 #49

比如我为 Debian 的某个版本提供二进制包，我可以直接在系统里依赖库，比如 libcurl3。而且基于共享库版本控制，不用担心 API/ABI 变化。安全更新直接由发行版负责了。我也不用自己去编译一份 curl，为什么不用呢。

[fhc023]

@est 嗯 谢谢提醒 自己写的哪些项目分别有哪些依赖都在自动化脚本里 如果有哪个出了问题 grep 下就知道哪些需要重新 link 之后重新编译有 bug 的库 然后 link 一下就完了 不需要全部重新编译 我觉得问题应该不大。

[fhc023]

@iwtbauh # 54
你说的很有道理啊，可惜我的开发环境和部署环境不是同一个 distro。比如我在 arch 上依赖 ffmpeg 某个 shared lib 写了程序 在部署环境的 debian 里跑不起来 debian 官方可能都不提供我依赖的这个 lib 版本。

[fhc023]

@behanga 感觉更可能是图片啥的，毕竟一个 linux kernel image 也才几十 MB

[ysc3839]

@iwtbauh 那也不能怪操作系统啊，应用程序随意修改系统文件，在任何系统上都有可能出问题吧？

[kwest]

1. 方便分发和更新，动态库更新一处即可，而不必像静态库一样把所有依赖于该库的二进制文件全部更新。
2. 节省内存和硬盘，动态库代码段被所有依赖它的程序共享并在内存中只存在一份。