Jedan od programera iz Googlea na LLVM mailing listi o razvoju višeplatformske standardne C knjižnice (Libc) u sklopu LLVM projekta. Iz više razloga Google nije zadovoljan trenutnim libc-om (glibc, musl) i tvrtka je na putu da razvije novu implementaciju, za koju se predlaže da bude razvijena kao dio LLVM-a.
Razvoj LLVM-a nedavno je korišten kao osnova za izradu Googleovih alata za sklapanje. Glavna ideja je da ako je Google već počeo razvijati svoj libc, zašto onda odmah ne razviti svoj sustav kao dio LLVM-a, koji već nudi vlastitu standardnu biblioteku za C++ (Libc++), ali nema sličnu standardnu biblioteku za C (libc).
Planirano je da se razvoj odvija u fazama, postupno povećavajući funkcionalnost. Predlaže se da prve opcije budu dizajnirane kao sloj između aplikacije i sustava Libc, iz kojeg će se posuditi značajke koje još nisu implementirane. Nakon postizanja određene razine funkcionalnosti, novi Libc se može koristiti kao potpuna zamjena za sustav Libc. Planiramo započeti s podrškom za x86-64 arhitekturu, Linux i statičko povezivanje (dinamičko učitavanje, povezivanje i dodatne arhitekture bit će implementirane sekundarno).
Projekt je još u ranoj fazi razvoja, ali su osnovni ciljevi već definirani:
- Modularnost i razvoj u skladu s filozofijom isporuke granularne knjižnice umjesto monolitnog skupa;
- Podrška za statičko povezivanje u načinima (Izvršne datoteke neovisne o poziciji) i bez PIE. Pružanje CRT (C runtime) i PIE punjača za statički povezane izvršne datoteke;
- Podrška za većinu standardnih funkcija C knjižnice, s POSIX dodacima i nekim proširenjima specifičnim za sustav koje zahtijevaju postojeće aplikacije;
- Budite oprezni s proširenjima specifičnim za dobavljače i dodajte ih samo kada je to potrebno. Što se tiče podrške za proširenja trećih strana, predlaže se korištenje pristupa projekata Clang i libc++;
- Korištenje najboljih praksi u razvoju pomoću alata LLVM, kao što je korištenje sredstva za čišćenje i testiranje dlačica od samog početka.
Jedan od aktivnih LLVM programera Jasno je da ima smisla slati libc kao dio LLVM alata, ali obično, kada se pojavi takva potreba, koriste musl biblioteku, koja je dobro napisana, podržava različite arhitekture i pruža potrebnu funkcionalnost, uključujući podršku za dinamičke povezivanje. Možda bi bilo opravdano ugraditi musl u LLVM i razviti ga kao fork sinkroniziran s glavnim projektom.
Vaše mišljenje također Autor Musl projekta, koji je pokušao argumentirati zašto su Googleov prijedlog i uključivanje Libc-a u LLVM distribuciju vrlo loše ideje:
- Razvijanje i održavanje ispravnog, kompatibilnog i visokokvalitetnog Libc-a vrlo je težak zadatak. Problem nije u količini koda, već u osiguravanju ispravnog ponašanja i poteškoćama u implementaciji sučelja, uzimajući u obzir ogroman sloj aplikacija ikada napisanih u C/C++, kao i aplikacija na drugim jezicima, čije se vrijeme izvođenja koristi od Libc. Neposredni pristup bez uzimanja u obzir nijansi samo će dovesti do činjenice da mnogi postojeći programi neće moći raditi s Libc-om, ali tada takav projekt neće biti od interesa za potrošače.
- Korporativni razvoj može uništiti Libc, ali ga gurnuti u široku upotrebu, što rezultira potrebom dodavanja hakova kako bi se osigurala kompatibilnost u aplikacijama. Razvoj pod okriljem korporativnog projekta otvorenog koda povući će deku prema potrebama i rješenjima tvrtke, a nauštrb interesa zajednice. Na primjer, ako identificirate problem koji je uzrokovan greškom u drugom programu, u kontroliranom razvoju lakše je osigurati da je Libc kompatibilan s ovom greškom nego popraviti samu grešku. Apple za te svrhe koristi BSD libc fork, a Google koristi musl fork u Fuchsia. Iskustvo programera musl-a je da su ga kontaktirali uglavnom odvjetnici kako bi razjasnili probleme s licencama, ali nikad ga nisu kontaktirali radi razjašnjenja tehničkih detalja prije unošenja beskorisnih i ometajućih promjena u njegovim ograncima.
- Odsutnost monokulture u razvoju libc-a i fokus na standarde vođene konsenzusom, a ne na individualnu kontrolu, što motivira programere aplikacija da koriste standarde, a ne da budu vezani uz specifične implementacije. Zato je autor musl-a protiv uključivanja njegove biblioteke u LLVM, kao i protiv razvoja libc-a unutar LLVM-a, budući da se u tom slučaju gubi neovisna priroda libc-a i određena implementacija postaje prvorazredno rješenje za LLVM, a svi ostali postaju drugorazredno rješenje.
Izvor: opennet.ru