Eden od Googlovih razvijalcev je na poštnem seznamu LLVM predstavil temo razvoja standardna knjižnica C za več platform (Libc) v okviru projekta LLVM.
Iz več razlogov Google ni zadovoljen s trenutno libc (glibc, musl) in podjetje je na dobri poti, da razvije novo izvedbo, ki ga namerava razviti v okviru LLVM. Razvoj LLVM je bil nedavno uporabljen kot osnova za izdelavo Googlovih orodij.
Načrtuje se razvoj postopno, postopno povečevanje funkcionalnosti. Predlagano je, da so prve možnosti v obliki vmesnega sloja med aplikacijo in sistemom libc, iz katerega bodo izposojene nerealizirane funkcije.
Po doseganju določene ravni funkcionalnosti se lahko novi Libc uporablja kot popolna zamenjava za sistem Libc.
Začeti načrtujemo s podporo za arhitekturo x86-64, Linux in statično vezavo (drugo dinamično nalaganje, pakiranje in dodatne arhitekture).
Projekt je še v začetni fazi razvoja, vendar so osnovni cilji že določeni:
- Modularnost in razvoj v skladu s filozofijo dobave granulirane knjižnice, ne pa monolitni ansambel.
- Podpora statični povezavi v načinu PIE (izvršilne datoteke, neodvisne od položaja) in brez PIE. Zagotovite CRT (C Runtime) in PIE loader za statično povezane izvršljive datoteke.
- Podpira večino funkcij knjižnice C. standardno z vtičniki POSIX in nekaterimi sistemsko razširjenimi razširitvami, ki se zahtevajo v obstoječih aplikacijah.
- Previden odnos do določenih podaljškov od ponudnika in jih dodaja le po potrebi. Pri podpori neodvisnih proizvajalcev je predlagana uporaba projektnega pristopa Clang in libc ++.
- Uporaba najboljših praks pri razvoju z uporabo orodij LLVM, na primer nanašanje razkužil in odprava testov od začetka.
Eden od aktivnih razvijalcev LLVM je to navedel dostava libc kot del zbirke orodij LLVM ni brez pomena, toda na splošno s tako potrebo uporabljajo musl knjižnico, Je dobro napisan, podpira več arhitektur in nudi potrebno funkcionalnost, vključno z dinamičnim povezovanjem.
Vključitev Musla v LLVM in njegov razvoj kot sinhroniziranih vilic z glavnim projektom je lahko upravičena.
Njegovo mnenje je izrazil tudi avtor projekta Musl, ki je poskušal argumentirati, zakaj sta Googlov predlog in vključitev Libca v dostavo LLVM zelo slabi ideji:
Razvoj in vzdrževanje pravilnega, združljivega in kakovostnega libc je zelo težka naloga. Težava ni v količini kode, temveč v zagotavljanju pravilnega vedenja.
In težave pri izvedbi vmesnika, glede na ogromno skladišče aplikacij, napisanih v C / C ++, pa tudi aplikacij v drugih jezikih, katerih izvajalno okolje uporablja Libc.
Pristop k čelu brez upoštevanja odtenkov bo privedel le do tega, da številni obstoječi programi ne bodo mogli sodelovati z Libcem, vendar takšen projekt ne bo zanimiv za potrošnike.
Korporativni razvoj lahko uniči Libc, vendar spodbujajo široko uporabo, kar bo povzročilo potrebo po dodajanju vdorov, da se zagotovi združljivost aplikacij.
Razvoj pod okriljem odprtega korporativnega projekta bo usmerjal pokritost k potrebam in odločitvam podjetja na škodo interesov skupnosti.
Na primer, v primeru prepoznavanja težave, ki jo je povzročila napaka v drugem vašem programu, je v nadzornem razvoju lažje zagotoviti združljivost Libc s to napako kot pa samo napako popraviti.
Apple za te namene uporablja vilice BSD libc, Google pa vilice Fuchsia. Muslove izkušnje na področju razvijalcev kažejo, da so ga odvetniki kontaktirali predvsem zaradi razjasnitve vprašanj licenciranja.