Üks Google'i arendajatest LLVM-i meililistis mitme platvormi standardse C-teegi (Libc) arendamise kohta LLVM-i projekti raames. Mitmel põhjusel ei ole Google rahul praeguse libc-ga (glibc, musl) ning ettevõte on teel uue juurutuse väljatöötamisse, mida soovitatakse arendada LLVM-i osana.
LLVM-i arendusi on hiljuti kasutatud Google'i koostetööriistade loomise aluseks. Põhiidee on selles, et kui Google on juba alustanud oma libc arendamist, siis miks mitte kohe arendada oma süsteemi LLVM-i osana, mis juba pakub oma standardteeki C++ jaoks (Libc++), kuid millel puudub C jaoks sarnane standardteeki. (libc).
Arendustööd on plaanis läbi viia etapiviisiliselt, suurendades järk-järgult funktsionaalsust. Esimesed võimalused on kavandatud kujundada rakenduse ja süsteemi Libc vahelise kihina, kust laenatakse veel juurutamata funktsioone. Pärast teatud funktsionaalsuse taseme saavutamist saab uut Libc-d kasutada süsteemi Libc täieliku asendajana. Alustada plaanime x86-64 arhitektuuri, Linuxi ja staatilise linkimise toega (sekundaarselt rakendatakse dünaamilist laadimist, linkimist ja lisaarhitektuure).
Projekt on alles algfaasis, kuid põhieesmärgid on juba määratletud:
- Modulaarsus ja arendus vastavalt filosoofiale, mille kohaselt tarnitakse pigem granuleeritud raamatukogu kui monoliitne komplekt;
- Staatilise linkimise tugi režiimides (Positsioonist sõltumatud käivitatavad failid) ja ilma PIE-ta. CRT (C runtime) ja PIE-laaduri pakkumine staatiliselt lingitud käivitatavate failide jaoks;
- Enamiku standardsete C teegi funktsioonide tugi koos POSIX-i täiendustega ja mõnede süsteemispetsiifiliste laiendustega, mida olemasolevad rakendused nõuavad;
- Olge tarnijapõhiste laiendustega ettevaatlik ja lisage need ainult vajaduse korral. Mis puutub kolmandate osapoolte laienduste toetamisse, siis tehakse ettepanek kasutada Clangi ja libc++ projektide lähenemisviisi;
- LLVM-i tööriistakomplekti kasutades arenduse parimate tavade kasutamine, näiteks puhastusvahendi ja udutesti kasutamine algusest peale.
Üks aktiivseid LLVM-i arendajaid On selge, et libc on mõttekas tarnida osana LLVM-i tööriistakomplektist, kuid tavaliselt kasutavad nad vajaduse korral musli teeki, mis on hästi kirjutatud, toetab erinevaid arhitektuure ja pakub vajalikke funktsioone, sealhulgas dünaamilist tuge. linkimine. Musli LLVM-i manustamine ja põhiprojektiga sünkroniseeritud kahvlina arendamine võib olla põhjendatud.
Sinu arvamus ka Musli projekti autor, kes püüdis argumenteerida, miks Google'i ettepanek ja Libc kaasamine LLVM-i distributsiooni on väga halvad mõtted:
- Õige, ühilduva ja kvaliteetse Libc arendamine ja säilitamine on väga keeruline ülesanne. Probleem ei ole mitte koodi koguses, vaid korrektse käitumise tagamises ja liideste juurutamise raskustes, võttes arvesse tohutut rakenduste kihti, mis kunagi C/C++ keeles kirjutatud, aga ka teistes keeltes rakendusi, mille tööaega kasutatakse autor Libc. Otse lähenemine ilma nüansse arvestamata viib ainult selleni, et paljud olemasolevad programmid ei saa Libc-ga töötada, kuid siis ei paku selline projekt tarbijatele huvi.
- Ettevõtte areng võib Libci rikkuda, kuid surub selle laialdaseks kasutamiseks, mille tulemuseks on vajadus lisada häkke, et tagada rakenduste ühilduvus. Ettevõtete avatud lähtekoodiga projekti egiidi all toimuv arendus tõmbab ühiskonna huvide arvelt tekki ettevõtte vajaduste ja lahenduste suunas. Näiteks kui tuvastate mõne teise programmi veast põhjustatud probleemi, on kontrollitud arenduses lihtsam tagada, et Libc ühildub selle veaga, kui viga ise parandada. Apple kasutab nendel eesmärkidel BSD libc kahvlit ja Google kasutab fuksia keeles musli kahvlit. Musli arendaja kogemus ütleb, et temaga võtsid litsentsiküsimuste selgitamiseks ühendust peamiselt juristid, kuid temaga ei võetud kunagi ühendust tehniliste üksikasjade täpsustamiseks enne, kui ta tegi oma filiaalides kasutuid ja häirivaid muudatusi.
- Monokultuuri puudumine libc arenduses ja keskendumine konsensuspõhistele standarditele, mitte individuaalsele kontrollile, mis motiveerib rakenduste arendajaid pigem standardeid kasutama kui olema seotud konkreetsete rakendustega. Seetõttu on musli autor nii oma raamatukogu lisamise vastu LLVM-i kui ka libc arendamisele LLVM-is, kuna sel juhul kaob libc iseseisvus ja teatud teostus muutub esmaklassiliseks lahenduseks. LLVM ja kõik teised muutuvad teise klassi lahenduseks.
Allikas: opennet.ru