Een van die ontwikkelaars van Google op die LLVM-poslys oor die ontwikkeling van 'n multi-platform standaard C-biblioteek (Libc) as deel van die LLVM-projek. Om 'n aantal redes is Google nie tevrede met die huidige libc (glibc, musl) nie en die maatskappy is op pad om 'n nuwe implementering te ontwikkel, wat voorgestel word om as deel van LLVM ontwikkel te word.
LLVM-ontwikkelings is onlangs gebruik as die basis vir die bou van Google se monteergereedskap. Die hoofgedagte is dat as Google reeds sy libc begin ontwikkel het, hoekom dan nie dadelik sy stelsel ontwikkel as deel van LLVM nie, wat reeds sy eie standaardbiblioteek vir C++ (Libc++) bied, maar nie 'n soortgelyke standaardbiblioteek vir C het nie. (libc).
Ontwikkeling word beplan om in fases uitgevoer te word, wat funksionaliteit geleidelik verhoog. Die eerste opsies word voorgestel om ontwerp te word as 'n laag tussen die toepassing en die stelsel Libc, waaruit kenmerke wat nog nie geïmplementeer is nie, geleen sal word. Nadat 'n sekere vlak van funksionaliteit bereik is, kan die nuwe Libc gebruik word as 'n volledige plaasvervanger vir die stelsel Libc. Ons beplan om te begin met ondersteuning vir x86-64-argitektuur, Linux en statiese koppeling (dinamiese laai, koppeling en bykomende argitekture sal sekondêr geïmplementeer word).
Die projek is nog in die aanvanklike stadium van ontwikkeling, maar basiese doelwitte is reeds gedefinieer:
- Modulariteit en ontwikkeling in ooreenstemming met die filosofie van die lewering van 'n korrelige biblioteek eerder as 'n monolitiese stel;
- Ondersteuning vir statiese koppeling in modusse (Posisie-onafhanklike uitvoerbare) en sonder PIE. Die verskaffing van CRT (C runtime) en PIE-laaier vir staties gekoppelde uitvoerbare;
- Ondersteuning vir die meeste van die standaard C-biblioteekfunksies, met POSIX-byvoegings en sommige stelselspesifieke uitbreidings wat deur bestaande toepassings vereis word;
- Wees versigtig met verskafferspesifieke uitbreidings en voeg dit net by wanneer nodig. Wat ondersteuning vir derdeparty-uitbreidings betref, word voorgestel om die benadering van die Clang- en libc++-projekte te gebruik;
- Die gebruik van beste praktyke in ontwikkeling deur die LLVM-gereedskapstel te gebruik, soos die gebruik van ontsmettingsmiddel en fuzz-toetsing van die begin af.
Een van die aktiewe LLVM-ontwikkelaars Dit is duidelik dat dit sin maak om libc as deel van die LLVM-gereedskapstel te stuur, maar gewoonlik, wanneer so 'n behoefte ontstaan, gebruik hulle die musl-biblioteek, wat goed geskryf is, verskeie argitekture ondersteun en die nodige funksionaliteit verskaf, insluitend ondersteuning vir dinamiese skakel. Dit kan geregverdig wees om musl in LLVM in te sluit en dit te ontwikkel as 'n vurk wat met die hoofprojek gesinchroniseer word.
Jou mening ook Die skrywer van die Musl-projek, wat probeer redeneer het waarom Google se voorstel en die insluiting van Libc in die LLVM-verspreiding baie slegte idees is:
- Die ontwikkeling en instandhouding van 'n korrekte, versoenbare en hoë kwaliteit Libc is 'n baie moeilike taak. Die probleem lê nie in die hoeveelheid kode nie, maar in die versekering van korrekte gedrag en probleme met die implementering van koppelvlakke, met inagneming van die groot laag toepassings wat ooit in C/C++ geskryf is, sowel as toepassings in ander tale, waarvan die looptyd gebruik word deur Libc. ’n Kop-aan-benadering sonder om die nuanses in ag te neem, sal net daartoe lei dat baie bestaande programme nie met Libc sal kan werk nie, maar dan sal so ’n projek nie vir verbruikers van belang wees nie.
- Korporatiewe ontwikkeling kan Libc ruïneer, maar druk dit vir wydverspreide gebruik, wat lei tot die behoefte om hacks by te voeg om verenigbaarheid in toepassings te verseker. Ontwikkeling onder die vaandel van 'n korporatiewe oopbronprojek sal die kombers na die behoeftes en oplossings van die maatskappy trek, tot nadeel van die belange van die gemeenskap. Byvoorbeeld, as jy 'n probleem identifiseer wat deur 'n fout in 'n ander program veroorsaak word, is dit in beheerde ontwikkeling makliker om te verseker dat Libc versoenbaar is met hierdie fout as om die fout self reg te stel. Apple gebruik die BSD libc vurk vir hierdie doeleindes, en Google gebruik die muslvurk in Fuchsia. Die ervaring van die musl-ontwikkelaar is dat hy hoofsaaklik deur prokureurs gekontak is om lisensiëringskwessies uit te klaar, maar nooit gekontak is om tegniese besonderhede uit te klaar voordat nuttelose en ontwrigtende veranderinge aan sy takke gemaak is nie.
- Die afwesigheid van 'n monokultuur in libc-ontwikkeling en 'n fokus op konsensus-gedrewe standaarde eerder as individuele beheer, wat toepassingsontwikkelaars motiveer om standaarde te gebruik eerder as om aan spesifieke implementerings gekoppel te wees. Daarom is die skrywer van musl teen die insluiting van sy biblioteek in LLVM, sowel as teen die ontwikkeling van libc binne LLVM, aangesien in hierdie geval die onafhanklike aard van libc verlore gaan en 'n sekere implementering 'n eersteklas oplossing word vir LLVM, en alle ander word 'n tweedeklas oplossing.
Bron: opennet.ru