カーネルには割り込みとマジックナンバーに基づくAPIがあります。このAPIはあまりにも低いレベルであり、プログラマになじみがないのでlibcsが発明されました。カーネルAPIを直接呼び出す便利な関数を公開します。
事実1：LinuxカーネルAPIは非常に安定しているため、古いmuslに静的に接続されているアプリケーションでは、以前のカーネルAPIの動作がまだ有効であると予想できます。
事実2：静的リンクがアプリケーションに接続され、アプリケーション全体がカーネルAPIを直接呼び出すことができます。
事実3：静的にリンクされたmuslでコンパイルされたアプリケーションは、ベアカーネルAPIのみを使用してLinuxの現在および将来のバージョンで実行されます。
それでは、なぜいくつかのディストリビューションでは明示的なmuslサポートがありますか？ Linux互換のカーネルAPIだけで十分ではありませんか？
私の質問に答えることができないので、私の「事実」のいくつかは無効なようです。
ベストアンサー1
3つの事実は、少なくともCライブラリ（上位レベル）に必要なものを理解するのに十分正確です。
私が考えるのに有効ではないのは、「明示的なmuslサポート」のあなたの理解です。持つ3種類の分布muslの観点から見ると：
- Alpineのように、ソフトウェア全体または大部分を構築するためにmuslをCライブラリとして使用するディストリビューションは、インストールサイズを減らすために頻繁に行われます（muslはGNU Cライブラリよりはるかに小さいため）。
- 展開がありません組み込みマスラーをサポートしてください。
- ユーザーにmuslをサービスとして提供しますが、それに依存しないディストリビューションです。
他のバイナリと同様に、必要なライブラリを提供する限り、すべてのLinuxディストリビューションでmusl依存のバイナリを使用できます。静的にリンクされている場合は、ライブラリを提供する必要はありません。展開自体には特別な要件はありません。
上記の3番目のタイプについて疑問に思うかもしれません。 musl に依存しないディストリビューションに musl を提供することは、musl を使用してバイナリを構築するユーザーが簡単に作成できるようにするためです。これらのディストリビューションは、muslライブラリ（通常は静的および動的）、ヘッダファイル、および必要なコンパイラサポートを提供します。 muslを使用してバイナリを構築します。つまり、ユーザーはmuslをインストールし、コンパイラを直接設定しなくてもmuslを使用してバイナリの構築を開始できます。
一般に、一部のディストリビューションは特定の機能をサポートし、他のディストリビューションはその機能をサポートしないという意味ではなく、エンドユーザーが関連するタスクを実行する必要があることを意味します。