Üks Google'i arendajatest esitas LLVM-i meililistis arendamise teema platvormiülene standardne C-teek (Libc) LLVM projekti raames.
Mitmel põhjusel Google pole praeguse libc-ga rahul (glibc, musl) ja ettevõte on uue rakenduse väljatöötamisel õigel teel, mida ta kavatseb välja töötada LLVMi osana. LLVM-i arendusi on hiljuti kasutatud Google'i tööriistade ehitamise aluseks.
Areng on kavandatud järk-järgult, suurendades järk-järgult funktsionaalsust. Esimesed valikud tehakse ettepanekuks rakenduse ja libc-süsteemi vahelise vahekihi kujul, kust realiseerimata tunnused laenatakse.
Pärast teatud funktsionaalsuse saavutamist saab uut Libc-i kasutada Libc-süsteemi täieliku asendajana.
Plaanis on alustada x86-64 arhitektuuri, Linuxi ja staatilise sidumise toega (dünaamiline laadimine, pakendamine ja täiendavad arhitektuurid rakendatakse teiseks).
Projekt on alles arengufaasis, kuid põhieesmärgid on juba määratletud:
- Modulaarsus ja areng vastavalt granuleeritud raamatukogu varustamise filosoofiale, mitte monoliitne ansambel.
- Staatilise lingi tugi PIE-režiimides (asukohast sõltumatud käivitatavad failid) ja ilma PIE-ta. Pakkuge staatiliselt lingitud käivitatavate failide jaoks CRT (C-käitusaeg) ja PIE-laadur.
- Toetab enamikku C-teegi funktsioonidest standard koos POSIX-pistikprogrammidega ja mõned süsteemipõhised laiendused, mida on vaja olemasolevates rakendustes.
- Ettevaatlik suhtumine konkreetsetesse pikendustesse pakkujalt ja lisate need ainult vajadusel. Kolmanda osapoole laienduse toetamiseks on soovitatav kasutada projekti lähenemist Clang ja libc ++.
- Parimate tavade kasutamine arenduses LLVM-i tööriistade abilnagu desinfektsioonivahendite pealekandmine ja testide kõrvaldamine algusest peale.
Üks aktiivsetest LLVM-i arendajatest märkis seda libc kohaletoimetamine osana LLVM-i tööriistakomplektist see pole tähendusetu, kuid tavaliselt kasutavad nad sellise vajadusega musliteeki, See on hästi kirjutatud, toetab mitut arhitektuuri ja tagab vajaliku funktsionaalsuse, sealhulgas dünaamilise linkimise.
Musli inkorporeerimine LLVM-i ja selle arendamine sünkroniseeritud kahvlina põhiprojektiga võib olla õigustatud.
Tema arvamust avaldas ka Musli projekti autor, kes üritas argumenteerida, miks on Google'i ettepanek ja Libci lisamine LLVM-i edastamisse väga halvad ideed:
Õige, ühilduva ja kvaliteetse libc arendamine ja hooldamine on väga keeruline ülesanne. Probleem pole mitte koodi mahus, vaid õige käitumise pakkumises.
Ja raskused liidese juurutamisel, arvestades C / C ++ -s kirjutatud rakenduste tohutut hoidlat, aga ka teistes keeltes olevate rakenduste, mille käitust Libc kasutab.
Lähenemine otsmikule ilma nüansse arvestamata viib ainult selleni, et paljud olemasolevad programmid ei saa Libciga koostööd teha, kuid selline projekt ei paku tarbijatele huvi.
Ettevõtte areng võib Libcit rikkuda, kuid juhib laialdast kasutamist, mille tulemuseks on vajadus lisada häkke, et tagada rakenduste ühilduvus.
Avatud korporatiivse projekti egiidi all olev arendus suunab ettevõtte vajadusi ja otsuseid kajastama, kahjustades kogukonna huve.
Näiteks mõne muu teie enda programmi veast põhjustatud probleemi tuvastamise korral on kontrolli all olevas arenduses lihtsam tagada Libc-i ühilduvus selle veaga kui vea enda parandamine.
Apple kasutab selleks otstarbeks kahvlit BSD libc ja Google Fuksi kahvlit. Musli arendajakogemus näitab, et advokaadid võtsid temaga ühendust peamiselt litsentsimise probleemide selgitamiseks.
allikas: http://lists.llvm.org