其次就是静态编译对 ram 和 rom 较少的嵌入式设备太不友好。别说全用静态编译了，只要有少数几个应用是自带库编译的，那 ram 和 rom 就得爆炸了。
一个程序只做一件事，可能有人会鄙夷这种 unix 哲学。不过在我看来，这是提升一个信息系统整体鲁棒性、安全性的很好的原则。各司其职可能在执行上效率不是最高的，但是当有问题发生时，能更好地处理。
动态静态其实还有一个授权协议的问题，不过这个问题不是十分紧要，foss 软件一般都不会触犯这个问题。
这是发生在我公司的真实案例，还好客户就在本市，修复很快，不用赔钱
嵌入式还是老老实实用 C 吧，rust 现在也可以考虑。go 就算了，自带 GC 就已经注定它不适合用于嵌入式了。
没有 ABI 兼容性这一说吗？
从 py2 到 py3 搞一趟，就知道依赖不定死版本活该整天处理垃圾！！！
依赖一个类似 fastjson 的库活该整天升级！！
现在磁盘不值钱，网络不值钱，查问题的时间比较值钱！！！这条黑了仨！！
静态链接有缺点，但动态链接难道就是完美的？就像前面有人提到的，更新一个 libcrypt 把 ssh 炸了。虽然这个我没遇到过，但我遇到过不少乱动 glibc 把包管理器炸掉的，我系统里至今留着一个 pacman-static，就是预防我哪天手贱。又比如 A 依赖旧版的 C，B 依赖新版的 C，在静态链接下完全不是问题，但动态链接下多来几个就有够你受的了。
为啥现在都用静态链接？因为「大多数时候」静态链接更方便，仅此而已。
升级所有依赖 tls 库的应用我没觉得有啥问题，任何一个有完善构建系统的公司做到这个不是很容易吗？至于那点网络流量和内存实在不值一提。
静态链接和动态链接只是个[权衡]，动态链接有你说的那些优势，静态链接同样也有很多优势。没有版本和依赖问题，容易发布容易维护，这是静态链接最大的优势，在 go 和 rust 的使用场景和生态下，静态链接是更优的选择。
cgo 动态 dll
“`
import (
“fmt”
“syscall”
“unsafe”
)
kernel32, _ = syscall.LoadLibrary(“kernel32.dll”)
getModuleHandle, _ = syscall.GetProcAddress(kernel32, “GetModuleHandleW”)
“`