文章探讨了C/C++在不同Linux发行版上的兼容性问题，以及由此带来的开发和分发困境。相较于Python、Java等语言，C/C++的兼容性问题更为突出，主要体现在标准库的频繁变动和不兼容性上。文章指出，这导致开发者倾向于使用旧的开发环境，软件需要发布多个变体以保证兼容性，或者依赖用户自行编译。作者进而提出了一个问题：为什么C/C++不像Java那样发布运行时环境，以简化软件分发？

🤔 C/C++ 兼容性挑战：与Python、Java等语言不同，C/C++在Linux下的兼容性问题更为突出。标准库的频繁变动和不兼容性，导致旧版C/C++程序无法在新版环境下运行，不同标准库（如glibc和musl-libc）之间也不兼容。

💡 开发者应对策略：为了解决兼容性问题，C/C++开发者常常选择使用旧的开发环境进行编译，以确保在旧版本Linux发行版上的运行。这与Python、Java等语言鼓励用户升级运行时环境的做法形成了鲜明对比。

📦 软件分发困境：C/C++软件为了兼容不同环境，不得不发布多个变体，或者干脆让用户自行编译。对于用户来说，这增加了使用门槛，尤其是在编译依赖复杂的软件时，手动搭建编译环境变得困难。

🤔 提出的问题：文章最终提出了一个问题：为什么C/C++不像Java那样，发布一个C/C++ Runtime，以简化软件分发和兼容性问题？

如题。现在的平台/编程语言运行时，按兼容性大致可以分成几类：

几乎不变动，程序可以动态链接/调用：POSIX API ，Win32 API ；经常变动，但可以自由安装：Python ，Java ，NodeJS ，C# .NET……；经常变动，但直接嵌入到编译后的程序：Go ，Rust……。

唯独 C 和 C++，在 Linux 下不仅经常变动，并且不向前兼容（即旧版 libc(++) 不能运行新版 libc(++) 的程序）、不互相兼容（ musl-libc 的程序不能用 glibc 运行），我在 Arch 上编译的程序几乎没法拿到 Ubuntu LTS 上运行，只能开个 Docker 容器来编译。

这就导致两个奇怪的现象：

在面向旧发行版开发 C/C++ 的时候，很多人宁愿自己搭古老开发环境来编译，也不愿/不能升级目标环境。而在 Python 、Java 之类的语言里，第一反应是直接给目标环境装个新版 Python/JRE 。很多 C/C++ 软件不得不发布一堆变体来保证兼容性（此外，C++ 还有 CXX11ABI 的兼容性问题），或者干脆让用户自己编译（然而用户并不是何时都有空、有能力搭环境，尤其是一些编译依赖非常复杂的软件）。

但似乎很少有人会专门去下载标准库实现。除了 Conda ，好像也没人关心怎么打包标准库。

为什么 C/C++ 不像 JRE 那样，发布一个 C/C++ Runtime 呢，这样分发软件不是方便得多吗？