LLVMメーリングリストで開発のトピックを提示したGoogle開発者のXNUMX人 クロスプラットフォームの標準Cライブラリ （Libc）LLVMプロジェクトのフレームワーク内。
いくつかの理由で、 Googleは現在のlibcに満足していません （glibc、musl） 同社は新しい実装の開発に向けて順調に進んでいます、彼はLLVMの一部として開発する予定です。 LLVMの開発は、最近Googleツールを構築するための基礎として使用されています。
開発は段階的に行われ、機能が徐々に増加する予定です。 最初のオプションは、アプリケーションとlibcシステムの間の中間層の形式であることが提案されており、そこから未実現の機能が借用されます。
一定レベルの機能に達した後、新しいLibcをLibcシステムの完全な代替として使用できます。
x86-64アーキテクチャ、Linux、および静的バインディングのサポートから開始する予定です（動的ロード、パッケージング、および追加のアーキテクチャがXNUMX番目に実装されます）。
プロジェクトはまだ開発の初期段階にありますが、基本的な目的はすでに定義されています。
- きめ細かいライブラリを提供するという哲学に従ったモジュール性と開発、モノリシックアンサンブルではなく。
- PIEモードでの静的リンクのサポート （位置に依存しない実行可能ファイル）およびPIEなし。 静的にリンクされた実行可能ファイルにCRT（Cランタイム）とPIEローダーを提供します。
- ほとんどのCライブラリ関数をサポートします POSIXプラグインと、既存のアプリケーションで要求されるいくつかのシステム固有の拡張機能を備えた標準。
- 特定の拡張機能に対する慎重な態度 プロバイダーから、必要な場合にのみ追加します。 サードパーティの拡張機能をサポートするには、Clangおよびlibc ++プロジェクトアプローチを使用することをお勧めします。
- LLVMツールを使用した開発でのベストプラクティスの使用消毒剤の塗布や最初からの検査の廃止など。
アクティブなLLVM開発者のXNUMX人は、 LLVMツールキットの一部としてのlibc配信 それは意味がないわけではありませんが、一般的にそのような必要性がある場合、彼らはmuslライブラリを使用します。 それはよく書かれていて、複数のアーキテクチャをサポートし、ダイナミックリンクを含む必要な機能を提供します。
MuslをLLVMに組み込み、メインプロジェクトとの同期フォークとして開発することは正当化できます。
彼の意見は、Muslプロジェクトの作者によっても表明されました。彼は、Googleの提案とLLVM配信にLibcを含めることが非常に悪い考えである理由を議論しようとしました。
正しく、互換性があり、高品質のlibcを開発して維持することは、非常に難しい作業です。 問題はコードの量ではなく、正しい動作を提供することにあります。
そして、C / C ++で書かれたアプリケーションの巨大なリポジトリ、およびランタイムがLibcによって使用される他の言語のアプリケーションを考慮すると、インターフェイスの実装の難しさ。
ニュアンスを考慮しない額へのアプローチは、多くの既存のプログラムがLibcで動作できないという事実につながるだけですが、そのようなプロジェクトは消費者の興味を引くことはありません。
企業の発展はLibcを台無しにする可能性があります、ただし、広く使用されるようになるため、アプリケーションの互換性を確保するためにハックを追加する必要があります。
オープンな企業プロジェクトの後援の下での開発は、コミュニティの利益を損なうことで、企業のニーズと決定に向けたカバレッジを推進します。
たとえば、独自の別のプログラムのエラーによって引き起こされた問題を特定する場合、制御下の開発では、エラー自体を修正するよりも、Libcとこのエラーの互換性を保証する方が簡単です。
Appleはこれらの目的でBSDlibcフォークを使用し、GoogleはFuchsiaフォークを使用します。 Muslの開発者の経験は、弁護士が主にライセンスの問題を明確にするために彼に連絡したことを示唆しています。