内核有基于中断和幻数的 API。这个API太底层了，对程序员来说不友好，所以libcs就被发明了。它们公开了方便的函数，可以直接调用内核 API。
事实1：Linux 内核 API 非常稳定，因此静态链接到旧 musl 的应用程序可以预期旧内核 API 行为仍然有效。
事实2：将 musl 静态链接到应用程序中，使整个应用程序直接调用内核 API。
事实 3：使用静态链接 musl 编译的应用程序将仅使用裸内核 API 在当前和未来版本的 Linux 上运行。
那么为什么有些发行版有明确的 musl 支持呢？拥有 Linux 兼容的内核 API 还不够吗？
我的一些“事实”一定是无效的，因为我无法回答我自己的问题。
答案1
你的三个事实足够准确，至少可以理解 C 库（在高层次上）需要什么。
我认为无效的是你对“明确的musl支持”的理解。有三种类型的分布从musl的角度来看：
- 使用 musl 作为 C 库构建全部或大部分软件的发行版，例如 Alpine；通常这样做是为了减少安装大小（因为 musl 比 GNU C 库小得多）；
- 没有任何的发行版内置支持穆斯勒；
- 为用户提供 musl 作为服务但不依赖它的发行版。
与任何其他二进制文件一样，您可以在任何 Linux 发行版上使用依赖于 musl 的二进制文件，只要您还提供所需的库。如果它是静态链接的，则无需提供库。对发行版本身没有具体要求。
您可能想知道上面的第三种类型。在不依赖它的发行版中提供 musl 是为了让想要使用 musl 构建二进制文件的用户变得更简单：这些发行版提供 musl 库（通常是静态和动态）、头文件和编译器支持所需的使用 musl 构建二进制文件。这意味着用户可以开始使用 musl 构建二进制文件，而无需自己安装 musl 并配置编译器。
一般来说，某些发行版支持给定功能，而其他发行版不支持这一事实并不意味着后者不支持该功能；这意味着最终用户需要完成所涉及的工作。