Yksi Googlen kehittäjistä esitteli LLVM-postituslistalla kehityksen aiheen alustojen välinen standardi C-kirjasto (Libc) LLVM-projektin puitteissa.
Useista syistä, Google ei ole tyytyväinen nykyiseen libc: hen (glibc, muslimi) ja yritys on etenemässä uuden toteutustavan kehittämiseksi, jonka hän aikoo kehittää osana LLVM: ää. LLVM-kehityksiä on viime aikoina käytetty Google-työkalujen rakentamisen perustana.
Kehityksen on tarkoitus olla asteittaista, ja sen toiminnallisuutta lisätään vähitellen. Ehdotetaan, että ensimmäiset vaihtoehdot ovat sovelluksen ja libc-järjestelmän välisen välikerroksen muodossa, josta realisoitumattomat ominaisuudet lainataan.
Saavutettuaan tietyn toiminnallisuuden tason uutta Libc: tä voidaan käyttää Libc-järjestelmän täydellisenä korvaavana.
Se on tarkoitus aloittaa tukemalla x86-64-arkkitehtuuria, Linuxia ja staattista sidontaa (dynaaminen lataus, pakkaus ja lisäarkkitehtuurit toteutetaan toisena).
Hanke on vielä kehitysvaiheessa, mutta perustavoitteet on jo määritelty:
- Modulaarisuus ja kehitys rakeisen kirjaston toimittamisen filosofian mukaisesti, eikä monoliittinen kokonaisuus.
- Staattisen linkin tuki PIE-tiloissa (sijainnista riippumattomat suoritettavat) ja ilman PIE: tä. Tarjoa CRT (C Runtime) ja PIE-latausohjelma staattisesti linkitettyihin suoritettaviin tiedostoihin.
- Tukee suurinta osaa C-kirjastotoiminnoista vakiona POSIX-laajennuksilla ja joillakin järjestelmäkohtaisilla laajennuksilla, joita vaaditaan nykyisissä sovelluksissa.
- Huolellinen asenne tiettyihin laajennuksiin palveluntarjoajalta ja lisäämällä ne vain tarvittaessa. Kolmannen osapuolen laajennustukea varten ehdotetaan Clang- ja libc ++ -projektin käyttämistä.
- Parhaiden käytäntöjen käyttäminen kehityksessä LLVM-työkalujen avulla, kuten desinfiointiaineiden levittäminen ja testien poistaminen alusta alkaen.
Yksi aktiivisista LLVM-kehittäjistä ilmoitti sen libc-toimitus osana LLVM-työkalupakettia se ei ole merkityksetöntä, mutta yleensä tällaisella tarpeella he käyttävät musl-kirjastoa, Se on hyvin kirjoitettu, tukee useita arkkitehtuureja ja tarjoaa tarvittavat toiminnot, mukaan lukien dynaaminen linkitys.
Muslin sisällyttäminen LLVM: ään ja sen kehittäminen synkronoituna haarukana pääprojektin kanssa voi olla perusteltua.
Hänen mielipiteensä ilmaisi myös Musl-projektin kirjoittaja, joka yritti väittää, miksi Googlen ehdotus ja Libc: n sisällyttäminen LLVM-toimitukseen ovat erittäin huonoja ideoita:
Oikean, yhteensopivan ja korkealaatuisen libc: n kehittäminen ja ylläpito on erittäin vaikea tehtävä. Ongelma ei ole koodin määrässä, vaan oikean käyttäytymisen tarjoamisessa.
Ja käyttöliittymän käyttöönoton vaikeudet, kun otetaan huomioon C / C ++ -sovelluksella kirjoitettujen sovellusten valtava arkisto sekä sovellukset muilla kielillä, joiden ajonaikaa Libc käyttää.
Lähestymistapa otsaan ottamatta huomioon vivahteita johtaa vain siihen tosiasiaan, että monet olemassa olevat ohjelmat eivät pysty työskentelemään Libc: n kanssa, mutta tällainen projekti ei kiinnosta kuluttajia.
Yrityskehitys voi pilata Libc: n, mutta ajaa laajaa käyttöä, mikä johtaa tarpeeseen lisätä hakkereita yhteensopivuuden varmistamiseksi sovelluksissa.
Avoimen yritysprojektin suojeluksessa tapahtuva kehitys ohjaa kattavuutta kohti yrityksen tarpeita ja päätöksiä yhteisön etujen vahingoksi.
Esimerkiksi toisen oman ohjelman virheen aiheuttaman ongelman tunnistamisessa hallittavassa kehityksessä on helpompaa taata Libc-yhteensopivuus tämän virheen kanssa kuin itse virheen korjaaminen.
Apple käyttää BSD libc -haarukkaa näihin tarkoituksiin ja Google käyttää Fuchsia-haarukkaa. Muslin kehittäjäkokemus viittaa siihen, että lakimiehet ottivat yhteyttä häneen ensisijaisesti lisensointikysymysten selvittämiseksi.
lähde: http://lists.llvm.org