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

[fhc023]

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

[byteli]

很多是为了热更的

[expy]

作为用户还是喜欢普通应用层软件静态链接，下一个可执行文件到处都能跑。

[smdbh]

1. 并不够
2. 修改维护

[yanqiyu]

glibc：我现在要修一个 BUG，请问你准备更新几个软件呢

[fhc023]

仔细想了下。像底层库更新这种情况的话，用动态库确实可以不用让依赖它的库重新打包。如果接口和行为没有改变的话是很不错的，但是也是可能带来兼容性问题。比如，底层库做了个 breaking change，那后续的库如果不改动的话也不能跑了。目前这种情况主要是包管理器来做依赖检查，然后决定你不是能更新某个底层库的。所以我觉得各有利弊吧。

[kljsandjb]

不说磁盘，内存这玩意不管多大都是稀缺资源😂

[dalieba]

降低开发成本，尤其是几个程序或者操作都需要一个轮子的时候。

[dangyuluo]

建议读一读《程序员的自我修养-链接、装载和库》，有真相

[sdijeenx]

磁盘空间本来是够的，自从有了 SSD 之后又不够了；
内存空间本来是够的，自从有了 DDR4 之后又不够了。😂

[Ediacaran]

插件,或者方便替换

[hikkikuma1991]

有些库没办法被静态连接，以 glibc 那一坨为代表。golang 默认也是动态链接 glibc 的。

[a226679594]

https://docs.microsoft.com/en-us/windows/desktop/dlls/advantages-of-dynamic-linking

[fhc023]

@hikkikuma1991 长知识了 具体为啥必须要动态链接 大概是因为这个 https://skarnet.org/software/nsss/nsswitch.html

[enenaaa]

静态链接一个符号重名就能折腾死你。

[fhc023]

话说这个问题原来在 YC 上就有讨论 感觉水很深呐
http://harmful.cat-v.org/software/dynamic-linking/
https://news.ycombinator.com/item?id=9629663

[msg7086]

@fhc023 #25 所以发行版更新底层库都会保证 API 不会出现 breaking change。
比如 openssl 1.0.2 和 1.0.2abcdef....opqr 都是兼容的。
而且像是 libssl libc 这种库，正是动态链接的优势所在。系统库一更新，所有依赖的软件自动受益，即使你用的软件已经好几年不更新了，只要依赖的底层库更新，一样能修正掉对应的安全漏洞。

[reself]

代码上都要做解耦，讲究代码复用呢，为啥要反其道而行？

[bytelee]

难道动态库只是为了解决磁盘和内存空间不足的问题么？

[iwtbauh]

@fhc023 #25

这就是我为什么讨厌 windows 这种大泥球的原因之一啊。你要是 windows 用户，肯定知道臭名昭著的“ DLL 地狱”问题。DLL 地狱即一个新软件可以随意升级（或降级）现有软件依赖的 DLL 库，而应用程序通常需要特定版本的库，一旦没有特定版本的库，应用程序就会崩溃。

这就是因为 windows 技术上一开始没有做好共享库版本控制问题导致的。也就是你说的这个原因。现在为了保证前向兼容采用了一种极其丑陋的方法规避问题，但没能实际解决。

而 Unix 的世界里，共享库版本控制做的非常好，一种方法是库文件名后戳通常带有版本号，应用程序依赖 libxxx.so.1 然后系统将 libxxx.so.1 符号链接到 libxxx.so.1.2.3 等版本上，系统只管升级 libxxx.so.1.x.x，库开发者保证小版本变化不会引入回归。而引入回归的大版本通常也可以和旧版本库共存。除了这种方法，还有很多种方法，比如 glibc 的符号版本控制，还有 qt 的库版本控制。。

[littlewing]

你是不是对 shared library 有什么误解？ shared library 从来都是不使用从来解决内存和磁盘不够的问题的。