LLVM郵件列表中介紹了一位Google開發人員，主題是開發 跨平台標準C庫 （libc）在LLVM項目的框架內。
有幾個原因， Google對當前的libc不滿意 （glibc，musl） 該公司正按計劃開發新的實施方案，他打算將其開發為LLVM的一部分。 LLVM的開發最近已用作構建Google工具的基礎。
計劃逐步開發，逐步增加功能。 建議第一選項採用應用程序和libc系統之間的中間層的形式，將從中藉用未實現的功能。
在達到一定的功能水平之後，新的Libc可以完全替代Libc系統。
計劃從對x86-64架構，Linux和靜態綁定的支持開始（第二步將實現動態加載，打包和其他架構）。
該項目仍處於開發的初始階段，但是已經定義了基本目標：
- 模塊化和開發符合提供粒度庫的理念，而不是一個整體。
- PIE模式下的靜態鏈接支持 （與位置無關的可執行文件）且沒有PIE。 為靜態鏈接的可執行文件提供CRT（C運行時）和PIE加載程序。
- 支持大多數C庫功能 POSIX插件的標準配置和現有應用程序中要求的某些特定於系統的擴展。
- 謹慎對待特定擴展名 提供商提供的信息，僅在必要時添加它們。 對於第三方擴展支持，建議使用Clang和libc ++項目方法。
- 使用LLVM工具在開發中使用最佳實踐，例如從一開始就使用消毒劑和取消測試。
一位活躍的LLVM開發人員表示 作為LLVM工具包的一部分提供libc 這並非沒有意義，但通常他們有需要使用musl庫， 它寫得很好，支持多種體系結構，並提供必要的功能，包括動態鏈接。
將Musl併入LLVM中以及將其開發為與主要項目同步的分支是有道理的。
Musl項目的作者也表達了他的觀點，他試圖論證為什麼Google的提案以及在LLVM交付中包含Libc是非常糟糕的主意：
開發和維護正確，兼容和高質量的libc是一項非常艱鉅的任務。 問題不在於代碼量，而在於提供正確的行為。
考慮到用C / C ++編寫的應用程序的龐大存儲庫以及Libc使用其運行時的其他語言的應用程序，以及接口實現的困難。
在不考慮細微差別的情況下採用額頭方法只會導致以下事實：許多現有程序將無法與Libc配合使用，但這樣的項目將對消費者不感興趣。
企業發展可能會破壞Libc，但推動了廣泛的使用，這將導致需要添加黑客來確保應用程序的兼容性。
在公司開放項目的主持下進行的開發將推動針對公司的需求和決策的覆蓋，從而損害社區的利益。
例如，在識別由您自己的另一個程序的錯誤引起的問題的情況下，在受控制的開發中，保證Libc與該錯誤的兼容性比糾正錯誤本身要容易得多。
Apple為此目的使用BSD libc分支，而Google使用Fuchsia分支。 Musl的開發人員經驗表明，律師與他聯繫主要是為了澄清許可問題。