En av utviklerne fra Google på LLVMs e-postliste om utviklingen av et multi-plattform standard C-bibliotek (Libc) som en del av LLVM-prosjektet. Av flere årsaker er ikke Google fornøyd med dagens libc (glibc, musl), og selskapet er på vei til å utvikle en ny implementering, som foreslås utviklet som en del av LLVM.
LLVM-utviklinger har nylig blitt brukt som grunnlag for å bygge Googles monteringsverktøy. Hovedideen er at hvis Google allerede har begynt å utvikle sin libc, hvorfor ikke umiddelbart utvikle systemet sitt som en del av LLVM, som allerede tilbyr sitt eget standardbibliotek for C++ (Libc++), men ikke har et tilsvarende standardbibliotek for C (libc).
Utviklingen er planlagt utført i etapper, gradvis økende funksjonalitet. De første alternativene foreslås utformet som et lag mellom applikasjonen og systemet Libc, hvor funksjoner som ennå ikke er implementert vil bli lånt. Etter å ha nådd et visst funksjonsnivå, kan den nye Libc brukes som en komplett erstatning for systemet Libc. Vi planlegger å starte med støtte for x86-64-arkitektur, Linux og statisk kobling (dynamisk lasting, kobling og tilleggsarkitekturer vil bli implementert sekundært).
Prosjektet er fortsatt på et tidlig stadium av utviklingen, men grunnleggende mål er allerede definert:
- Modularitet og utvikling i samsvar med filosofien om å levere et granulært bibliotek i stedet for et monolitisk sett;
- Støtte for statisk kobling i moduser (Posisjonsuavhengige kjørbare filer) og uten PIE. Tilbyr CRT (C runtime) og PIE-laster for statisk koblede kjørbare filer;
- Støtte for de fleste standard C-biblioteksfunksjoner, med POSIX-tillegg og noen systemspesifikke utvidelser som kreves av eksisterende applikasjoner;
- Vær forsiktig med leverandørspesifikke utvidelser og legg dem bare til når det er nødvendig. Når det gjelder støtte for tredjepartsutvidelser, foreslås det å bruke tilnærmingen til Clang- og libc++-prosjektene;
- Bruk av beste praksis i utvikling ved å bruke LLVM-verktøysettet, for eksempel bruk av rensemiddel og fuzz-testing helt fra begynnelsen.
En av de aktive LLVM-utviklerne Det er tydelig at det er fornuftig å sende libc som en del av LLVM-verktøysettet, men vanligvis, når et slikt behov oppstår, bruker de musl-biblioteket, som er godt skrevet, støtter ulike arkitekturer og gir den nødvendige funksjonaliteten, inkludert støtte for dynamisk kobling. Det kan være berettiget å bygge inn musl i LLVM og utvikle den som en gaffel synkronisert med hovedprosjektet.
Din mening også Forfatteren av Musl-prosjektet, som prøvde å argumentere for hvorfor Googles forslag og inkluderingen av Libc i LLVM-distribusjonen er veldig dårlige ideer:
- Å utvikle og vedlikeholde en korrekt, kompatibel og høykvalitets Libc er en svært vanskelig oppgave. Problemet ligger ikke i mengden kode, men i å sikre korrekt oppførsel og vanskeligheter med å implementere grensesnitt, tatt i betraktning det enorme laget av applikasjoner som noen gang er skrevet i C/C++, samt applikasjoner på andre språk, hvis kjøretid brukes av Libc. En frontal tilnærming uten å ta hensyn til nyansene vil bare føre til at mange eksisterende programmer ikke vil kunne jobbe med Libc, men da vil ikke et slikt prosjekt være av interesse for forbrukerne.
- Bedriftsutvikling kan ødelegge Libc, men presse det for utbredt bruk, noe som resulterer i behovet for å legge til hacks for å sikre kompatibilitet i applikasjoner. Utvikling i regi av et bedriftsprosjekt med åpen kildekode vil trekke teppet mot bedriftens behov og løsninger, til skade for fellesskapets interesser. Hvis du for eksempel identifiserer et problem som er forårsaket av en feil i et annet program, er det i kontrollert utvikling lettere å sikre at Libc er kompatibel med denne feilen enn å fikse selve feilen. Apple bruker BSD libc-gaffelen til disse formålene, og Google bruker musl-gaffelen i Fuchsia. Erfaringen til musl-utvikleren er at han hovedsakelig ble kontaktet av advokater for å avklare lisensieringsspørsmål, men aldri ble kontaktet for å avklare tekniske detaljer før han gjorde ubrukelige og forstyrrende endringer i filialene sine.
- Fraværet av en monokultur i libc-utvikling og et fokus på konsensusdrevne standarder i stedet for individuell kontroll, noe som motiverer applikasjonsutviklere til å bruke standarder i stedet for å være knyttet til spesifikke implementeringer. Det er grunnen til at forfatteren av musl er imot inkluderingen av biblioteket sitt i LLVM, så vel som mot utviklingen av libc i LLVM, siden i dette tilfellet går den uavhengige naturen til libc tapt og en viss implementering blir en førsteklasses løsning for LLVM, og alle andre blir en annenrangs løsning.
Kilde: opennet.ru