Eden od razvijalcev iz Googla na poštnem seznamu LLVM o razvoju večplatformske standardne knjižnice C (Libc) v okviru projekta LLVM. Iz več razlogov Google ni zadovoljen s trenutno libc (glibc, musl) in podjetje je na poti k razvoju nove izvedbe, ki naj bi se razvila kot del LLVM.
Razvoj LLVM je bil nedavno uporabljen kot osnova za izdelavo Googlovih orodij za sestavljanje. Glavna ideja je, da če je Google že začel razvijati svoj libc, zakaj ne bi takoj razvil svojega sistema kot del LLVM, ki že ponuja lastno standardno knjižnico za C++ (Libc++), vendar nima podobne standardne knjižnice za C (libc).
Načrtuje se, da bo razvoj potekal po fazah, s postopnim povečevanjem funkcionalnosti. Predlagano je, da so prve možnosti zasnovane kot plast med aplikacijo in sistemom Libc, iz katere bodo izposojene funkcije, ki še niso bile implementirane. Po doseganju določene stopnje funkcionalnosti se lahko novi Libc uporablja kot popolna zamenjava za sistem Libc. Začeti nameravamo s podporo za arhitekturo x86-64, Linux in statično povezovanje (dinamično nalaganje, povezovanje in dodatne arhitekture bodo implementirane sekundarno).
Projekt je še v začetni fazi razvoja, vendar so osnovni cilji že definirani:
- Modularnost in razvoj v skladu s filozofijo zagotavljanja zrnate knjižnice namesto monolitnega sklopa;
- Podpora za statično povezovanje v načinih (izvršljive datoteke, neodvisne od položaja) in brez PIE. Zagotavljanje CRT (C runtime) in nalagalnik PIE za statično povezane izvedljive datoteke;
- Podpora za večino standardnih funkcij knjižnice C z dodatki POSIX in nekaterimi sistemsko specifičnimi razširitvami, ki jih zahtevajo obstoječe aplikacije;
- Bodite previdni pri razširitvah, specifičnih za prodajalca, in jih dodajte le, ko je to potrebno. Kar zadeva podporo za razširitve tretjih oseb, je predlagana uporaba pristopa projektov Clang in libc++;
- Uporaba najboljših praks pri razvoju z uporabo kompleta orodij LLVM, kot je uporaba razkužila in testiranje dlak od samega začetka.
Eden od aktivnih razvijalcev LLVM Jasno je, da je smiselno poslati libc kot del kompleta orodij LLVM, vendar običajno, ko se pojavi takšna potreba, uporabijo knjižnico musl, ki je dobro napisana, podpira različne arhitekture in zagotavlja potrebno funkcionalnost, vključno s podporo za dinamične povezovanje. Morda je upravičeno vdelati musl v LLVM in ga razviti kot fork, sinhroniziran z glavnim projektom.
Tudi vaše mnenje Avtor projekta Musl, ki je poskušal argumentirati, zakaj sta Googlov predlog in vključitev Libc v distribucijo LLVM zelo slabi ideji:
- Razvijanje in vzdrževanje pravilnega, združljivega in visokokakovostnega Libc je zelo težka naloga. Težava ni v količini kode, temveč v zagotavljanju pravilnega obnašanja in težavah pri izvajanju vmesnikov, upoštevajoč ogromno plast aplikacij, kadar koli napisanih v C/C++, pa tudi aplikacij v drugih jezikih, katerih čas izvajanja se uporablja avtor Libc. Neposredni pristop brez upoštevanja odtenkov bo privedel le do dejstva, da številni obstoječi programi ne bodo mogli delovati z Libc, potem pa tak projekt ne bo zanimiv za potrošnike.
- Korporacijski razvoj lahko uniči Libc, vendar ga potisne v široko uporabo, kar povzroči potrebo po dodajanju vdorov za zagotavljanje združljivosti v aplikacijah. Razvoj pod okriljem korporativnega odprtokodnega projekta bo potegnil odejo k potrebam in rešitvam podjetja, na škodo interesov skupnosti. Na primer, če prepoznate težavo, ki jo povzroča napaka v drugem programu, je pri nadzorovanem razvoju lažje zagotoviti, da je Libc združljiv s to napako, kot popraviti samo napako. Apple za te namene uporablja BSD libc fork, Google pa uporablja musl fork v Fuchsia. Izkušnje razvijalca musl kažejo, da so ga v glavnem kontaktirali odvetniki, da bi razjasnili težave z licenciranjem, nikoli pa ga niso kontaktirali, da bi razjasnili tehnične podrobnosti, preden je naredil neuporabne in moteče spremembe v svojih podružnicah.
- Odsotnost monokulture v razvoju libc in osredotočenost na standarde, ki temeljijo na soglasju, namesto na individualnem nadzoru, kar spodbuja razvijalce aplikacij, da uporabljajo standarde, namesto da bi bili vezani na posebne izvedbe. Zato je avtor musla proti vključitvi njegove knjižnice v LLVM, pa tudi proti razvoju libc znotraj LLVM, saj se v tem primeru izgubi neodvisna narava libc in določena izvedba postane prvovrstna rešitev za LLVM, vsi ostali pa postanejo drugorazredna rešitev.
Vir: opennet.ru