Vienas iš „Google“ kūrėjų LLVM adresatų sąraše apie daugiaplatforminės standartinės C bibliotekos (Libc) kūrimą kaip LLVM projekto dalį. Dėl daugelio priežasčių „Google“ nėra patenkinta esamu „libc“ (glibc, musl) ir įmonė ruošiasi kurti naują diegimą, kurį siūloma kurti kaip LLVM dalį.
LLVM plėtra neseniai buvo naudojama kaip „Google“ surinkimo įrankių kūrimo pagrindas. Pagrindinė mintis yra ta, kad jei Google jau pradėjo kurti savo libc, tai kodėl gi ne iš karto sukurti savo sistemą kaip dalį LLVM, kuri jau siūlo savo standartinę biblioteką C++ (Libc++), bet neturi panašios standartinės bibliotekos C. (libc).
Plėtrą planuojama vykdyti etapais, palaipsniui didinant funkcionalumą. Pirmuosius variantus siūloma projektuoti kaip sluoksnį tarp programos ir sistemos Libc, iš kurio bus pasiskolintos dar neįdiegtos funkcijos. Pasiekus tam tikrą funkcionalumo lygį, naujasis Libc gali būti naudojamas kaip pilnas Libc sistemos pakaitalas. Planuojame pradėti nuo x86-64 architektūros palaikymo, Linux ir statinio susiejimo (dinaminis įkėlimas, susiejimas ir papildomos architektūros bus įdiegtos antraeiliai).
Projektas dar tik pradiniame kūrimo etape, tačiau pagrindiniai tikslai jau apibrėžti:
- Moduliškumas ir plėtra pagal granuliuotos bibliotekos, o ne monolitinio rinkinio, pristatymo filosofiją;
- Statinio susiejimo palaikymas režimais (nuo pozicijos nepriklausomi vykdomieji failai) ir be PIE. CRT (C vykdymo laikas) ir PIE įkroviklio teikimas statiškai susietiems vykdomiesiems failams;
- Daugumos standartinių C bibliotekos funkcijų palaikymas su POSIX priedais ir kai kuriais sistemai būdingais plėtiniais, kurių reikia esamoms programoms;
- Būkite atsargūs su konkretaus tiekėjo plėtiniais ir pridėkite juos tik tada, kai reikia. Kalbant apie trečiųjų šalių plėtinių palaikymą, siūloma naudoti Clang ir libc++ projektų metodą;
- Geriausios praktikos panaudojimas kuriant naudojant LLVM įrankių rinkinį, pvz., dezinfekavimo priemonės ir pūkelių testavimas nuo pat pradžių.
Vienas iš aktyvių LLVM kūrėjų Aišku, kad prasminga siųsti libc kaip LLVM įrankių rinkinio dalį, tačiau paprastai, kai atsiranda toks poreikis, jie naudoja musl biblioteką, kuri yra gerai parašyta, palaiko įvairias architektūras ir suteikia reikiamą funkcionalumą, įskaitant dinaminio palaikymą. susiejimas. Gali būti pateisinama įterpti musl į LLVM ir sukurti kaip šakutę, sinchronizuotą su pagrindiniu projektu.
Jūsų nuomonė taip pat Musl projekto autorius, kuris bandė argumentuoti, kodėl Google pasiūlymas ir Libc įtraukimas į LLVM platinimą yra labai blogos mintys:
- Sukurti ir palaikyti teisingą, suderinamą ir aukštos kokybės Libc yra labai sudėtinga užduotis. Problema yra ne kodo kiekyje, o teisingo elgesio užtikrinime ir sąsajų diegimo sunkumuose, atsižvelgiant į didžiulį programų, kada nors parašytų C/C++, sluoksnį, taip pat programas kitomis kalbomis, kurių veikimo laikas yra naudojamas. pateikė Libc. Tiesioginis požiūris, neatsižvelgiant į niuansus, lems tik tai, kad daugelis esamų programų negalės dirbti su Libc, tačiau tada toks projektas nebus įdomus vartotojams.
- Įmonių plėtra gali sugadinti „Libc“, bet paskatinti ją plačiai naudoti, todėl norint užtikrinti programų suderinamumą, reikia pridėti įsilaužimų. Vystymas pagal korporatyvinį atvirojo kodo projektą trauks antklodę link įmonės poreikių ir sprendimų, o tai pakenks bendruomenės interesams. Pavyzdžiui, jei nustatote problemą, kurią sukėlė kitos programos klaida, kontroliuojamo kūrimo metu lengviau įsitikinti, kad Libc yra suderinamas su šia klaida, nei ištaisyti pačią klaidą. „Apple“ šiems tikslams naudoja BSD libc šakutę, o „Google“ naudoja musl šakutę fuksijoje. Musl kūrėjo patirtis rodo, kad su juo daugiausia susisiekė teisininkai, norėdami išsiaiškinti licencijavimo klausimus, tačiau su juo niekada nesikreipė dėl techninių detalių, prieš atlikdami nenaudingus ir trikdančius jo filialų pakeitimus.
- Monokultūros nebuvimas kuriant libc ir susitelkimas į sutarimu grindžiamus standartus, o ne vienintelę kontrolę, o tai skatina programų kūrėjus naudoti standartus, o ne būti susietiems su konkrečiais diegimais. Štai kodėl musl autorius yra prieš savo bibliotekos įtraukimą į LLVM, taip pat prieš libc plėtojimą LLVM viduje, nes tokiu atveju prarandamas nepriklausomas libc pobūdis ir tam tikras diegimas tampa aukščiausios klasės sprendimu LLVM, o visi kiti tampa antrarūšiu sprendimu.
Šaltinis: opennet.ru