En af udviklerne fra Google på LLVM-mailinglisten om udviklingen af et multi-platform standard C-bibliotek (Libc) som en del af LLVM-projektet. Af en række årsager er Google ikke tilfreds med den nuværende libc (glibc, musl), og virksomheden er på vej til at udvikle en ny implementering, som foreslås udviklet som en del af LLVM.
LLVM-udviklinger er for nylig blevet brugt som grundlag for at bygge Googles monteringsværktøjer. Hovedideen er, at hvis Google allerede er begyndt at udvikle sit libc, hvorfor så ikke straks udvikle sit system som en del af LLVM, som allerede tilbyder sit eget standardbibliotek til C++ (Libc++), men ikke har et tilsvarende standardbibliotek for C (libc).
Udvikling er planlagt til at blive udført i etaper, gradvist øge funktionaliteten. De første muligheder foreslås udformet som et lag mellem applikationen og systemet Libc, hvorfra funktioner, der endnu ikke er implementeret, vil blive lånt. Efter at have nået et vist niveau af funktionalitet, kan den nye Libc bruges som en komplet erstatning for systemet Libc. Vi planlægger at starte med understøttelse af x86-64-arkitektur, Linux og statisk linking (dynamisk indlæsning, linkning og yderligere arkitekturer vil blive implementeret sekundært).
Projektet er stadig på den indledende fase af udviklingen, men grundlæggende mål er allerede defineret:
- Modularitet og udvikling i overensstemmelse med filosofien om at levere et granulært bibliotek snarere end et monolitisk sæt;
- Understøttelse af statisk linking i tilstande (Positionsuafhængige eksekverbare filer) og uden PIE. Leverer CRT (C runtime) og PIE-indlæser til statisk forbundne eksekverbare filer;
- Understøttelse af de fleste standard C-biblioteksfunktioner med POSIX-tilføjelser og nogle systemspecifikke udvidelser, der kræves af eksisterende applikationer;
- Vær forsigtig med leverandørspecifikke udvidelser og tilføj dem kun, når det er nødvendigt. Med hensyn til understøttelse af tredjepartsudvidelser foreslås det at bruge tilgangen til Clang- og libc++-projekterne;
- Brug af bedste praksis i udvikling ved hjælp af LLVM-værktøjssættet, såsom brug af desinfektionsmiddel og fuzz-test fra begyndelsen.
En af de aktive LLVM-udviklere Det er klart, at det giver mening at sende libc som en del af LLVM-værktøjssættet, men normalt, når et sådant behov opstår, bruger de musl-biblioteket, som er velskrevet, understøtter forskellige arkitekturer og giver den nødvendige funktionalitet, herunder understøttelse af dynamisk forbinder. Det kan være berettiget at indlejre musl i LLVM og udvikle det som en gaffel synkroniseret med hovedprojektet.
Din mening også Forfatteren af Musl-projektet, som forsøgte at argumentere for, hvorfor Googles forslag og inkluderingen af Libc i LLVM-distributionen er meget dårlige ideer:
- At udvikle og vedligeholde en korrekt, kompatibel og højkvalitets Libc er en meget vanskelig opgave. Problemet ligger ikke i mængden af kode, men i at sikre korrekt adfærd og vanskeligheder med at implementere grænseflader under hensyntagen til det enorme lag af applikationer, der nogensinde er skrevet i C/C++, såvel som applikationer på andre sprog, hvis køretid bruges af Libc. En frontal tilgang uden at tage højde for nuancerne vil kun føre til, at mange eksisterende programmer ikke vil kunne arbejde med Libc, men så vil et sådant projekt ikke være interessant for forbrugerne.
- Virksomhedsudvikling kan ødelægge Libc, men skubbe det til udbredt brug, hvilket resulterer i behovet for at tilføje hacks for at sikre kompatibilitet i applikationer. Udvikling i regi af et virksomheds open source-projekt vil trække tæppet mod virksomhedens behov og løsninger til skade for samfundets interesser. For eksempel, hvis du identificerer et problem, der er forårsaget af en fejl i et andet program, er det i kontrolleret udvikling nemmere at sikre, at Libc er kompatibel med denne fejl end at rette selve fejlen. Apple bruger BSD libc-gaflen til disse formål, og Google bruger musl-gaffelen i Fuchsia. Musl-udviklerens erfaring er, at han hovedsageligt blev kontaktet af advokater for at afklare licensspørgsmål, men aldrig blev kontaktet for at afklare tekniske detaljer, før han lavede ubrugelige og forstyrrende ændringer i sine afdelinger.
- Fraværet af en monokultur i libc-udvikling og fokus på konsensus-drevne standarder frem for individuel kontrol, hvilket motiverer applikationsudviklere til at bruge standarder i stedet for at være bundet til specifikke implementeringer. Det er grunden til, at forfatteren af musl er imod inddragelsen af sit bibliotek i LLVM, såvel som imod udviklingen af libc inden for LLVM, da libc's selvstændige karakter i dette tilfælde går tabt, og en vis implementering bliver en førsteklasses løsning for LLVM og alle andre bliver en andenklasses løsning.
Kilde: opennet.ru