私は最近、非常に熟練したソフトウェアエンジニアである友人と話していましたが、彼は私にlibcがglibcよりはるかに優れていることを説明するいくつかの記事を見せました。
代わりにlibcを使用できるかどうか、このパスに行くとどの問題に直面するのか疑問に思います。
答え1
文脈：上記の説明で仮定すると、BSDishはlibcBSDishを意味します。
私はそれが研究されていますが、与えられlibcたカーネルに非常に縛られている傾向があると思います（glibc抽象化層がありますが、これは多少移植可能ですが、抽象化層によって引き起こされる一般的な問題につながります）。そしてlibcLinuxカーネルでBSDを作成します。ほぼ完全な書き換えが必要でした。主なシステムサービスは2つのシステム間で大きく異なります（たとえば、BSDはlibcソケットペアを使用するため、BSDにはパイプ/FIFOがないと仮定しますが、Linuxはパイプ互換ソケットペアをサポートしません）。
別の方向に行くこと（DebianはFreeBSDカーネルの上に実験的なLinuxユーザースペースを持っていると思います）は移植性層のおかげで可能ですglibc。
答え2
答え3
多くのソフトウェアはそれglibc自体、glibcマクロ、またはglibcスタイルにのみ依存するため、ビルドは失敗します。内部で何が起こっているのかを知ることで、glibcすべてのソフトウェアを簡単に修正できます。たとえば、ここで見ることができますLinuxヘッダファイルのためのmusl。ヘッダーはまだ完成していませんが、コミットを確認し、操作がどのように見えるかを確認できます。
glibcすべての開発者は基本システムを使用してソフトウェアをテストします。すべてのライブソフトウェア開発を修正し、正しいlibcソリューション（プル要求など）を使用して他のソフトウェアと互換性を持たせることはできません。したがって、このような汎用システムはgentoo無限の痛みなしに代替libcを使用して構築することはできません。
組み込み開発者（例openwrt：）は、ソフトウェアのバージョンを修正し、それを解決するために多くの作業を行っています。したがって、組み込みシステム（たとえばopenwrt）は、次の機能のみを提供できます。源泉muslあるいは、同じビルドに代替libcsを使用することもできますuclibc。
otherで置き換えるglibc痛みを伴わずに正しい唯一の方法は、otherを使用してすべての動作をシミュレートする特別なラッパーをlibc実装することです。今日、そのようなプロジェクトはありません。glibclibc