En av Google-utviklerne presenterte emnet for utvikling på LLVM-adresselisten et standard C-bibliotek på tvers av plattformer (Libc) innenfor rammen av LLVM-prosjektet.
Av flere grunner, Google er ikke fornøyd med den nåværende libc (glibc, musl) og selskapet er på vei til å utvikle en ny implementering, som han har tenkt å utvikle som en del av LLVM. LLVM-utvikling har nylig blitt brukt som grunnlag for å bygge Google-verktøy.
Utvikling er planlagt å være gradvis, og gradvis øke funksjonaliteten. Det foreslås at de første alternativene har form av et mellomlag mellom applikasjonen og libc-systemet, hvor de urealiserte funksjonene vil bli lånt.
Etter å ha nådd et visst nivå av funksjonalitet, kan den nye Libc brukes som en komplett erstatning for Libc-systemet.
Det er planlagt å starte med støtte for x86-64 arkitektur, Linux og statisk binding (dynamisk lasting, pakking og tilleggsarkitekturer implementeres andre).
Prosjektet er fortsatt i den innledende utviklingsfasen, men de grunnleggende målene er allerede definert:
- Modularitet og utvikling i samsvar med filosofien om å levere et granulært bibliotek, snarere enn et monolitisk ensemble.
- Statisk koblingsstøtte i PIE-modus (posisjonsuavhengige kjørbare filer) og uten PIE. Gi CRT (C Runtime) og PIE loader for statisk koblede kjørbare filer.
- Støtter de fleste C-biblioteksfunksjonene standard med POSIX-plugin-moduler og noen systemspesifikke utvidelser som etterspørres i eksisterende applikasjoner.
- Forsiktig holdning til spesifikke utvidelser fra leverandøren og bare legge dem til når det er nødvendig. For tredjeparts utvidelsesstøtte foreslås det å bruke prosjektet Clang og libc ++.
- Bruke beste praksis i utvikling ved hjelp av LLVM-verktøy, som påføring av desinfeksjonsmidler og eliminering av tester fra begynnelsen.
En av de aktive LLVM-utviklerne antydet det libc levering som en del av LLVM verktøykasse det er ikke uten mening, men generelt med et slikt behov bruker de muskelbiblioteket, Den er godt skrevet, støtter flere arkitekturer, og gir den nødvendige funksjonaliteten, inkludert dynamisk kobling.
Inkorporeringen av Musl i LLVM og dens utvikling som en synkronisert gaffel med hovedprosjektet kan rettferdiggjøres.
Hans mening ble også uttalt av forfatteren av Musl-prosjektet, som prøvde å argumentere for hvorfor Googles forslag og inkluderingen av Libc i LLVM-leveransen er veldig dårlige ideer:
Å utvikle og vedlikeholde riktig, kompatibel og høy kvalitet libc er en veldig vanskelig oppgave. Problemet ligger ikke i mengden kode, men i å gi riktig oppførsel.
Og vanskelighetene med grensesnittimplementering, med tanke på det enorme lageret av applikasjoner skrevet i C / C ++, samt applikasjoner på andre språk hvis kjøretid brukes av Libc.
Tilnærmingen til pannen uten å ta hensyn til nyansene vil bare føre til at mange eksisterende programmer ikke vil kunne jobbe med Libc, men et slikt prosjekt vil ikke være av interesse for forbrukerne.
Bedriftsutvikling kan ødelegge Libc, men kjør utbredt bruk, noe som vil resultere i behovet for å legge til hack for å sikre kompatibilitet i applikasjoner.
Utvikling i regi av et åpent selskapsprosjekt vil drive dekning mot selskapets behov og beslutninger, til skade for samfunnets interesser.
For eksempel, i tilfelle av å identifisere et problem forårsaket av en feil i et annet program, under utviklingen under kontroll, er det lettere å garantere kompatibiliteten til Libc med denne feilen enn å korrigere selve feilen.
Apple bruker BSD libc-gaffelen til disse formålene, og Google bruker Fuchsia-gaffelen. Musls utviklererfaring antyder at advokatene først og fremst kontaktet ham for å avklare lisensspørsmålene.
Fuente: http://lists.llvm.org