En af udviklerne fra Google emnet om udvikling af en multiplatform standard C-bibliotek (Libc) i LLVM-mailinglisten. Af forskellige grunde er Google utilfredse med de 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's funktionalitet har på det seneste været brugt som grundlag for at opbygge Google's byggeværktøjer. Hovedideen er, at hvis Google allerede er begyndt at udvikle sin libc, hvorfor så ikke udvikle sit system som en del af LLVM, som allerede tilbyder sit standardbibliotek for C++ (Libc++), men ikke har et tilsvarende standardbibliotek for C (Libc).
Udviklingen planlægges at være trinvis, hvor funktionaliteten gradvist øges. De første versioner foreslås at blive udformet som et lag mellem applikationen og det systembaserede Libc, fra hvilket der vil blive lånt endnu ikke implementerede funktioner. Efter at have nået et bestemt funktionsniveau, vil den nye Libc kunne anvendes som en fuld erstatning for systemets Libc. Den første støtte vil være til arkitektur x86-64, Linux og statisk binding (dynamisk indlæsning, sammenkobling, og yderligere arkitekturer skal implementeres som næste skridt).
Projektet er stadig i en tidlig udviklingsfase, men de grundlæggende mål er allerede defineret:
- Modularitet og udvikling i overensstemmelse med filosofien om at levere et granulært bibliotek i stedet for et monolitisk sæt;
- Understøttelse af statisk binding i tilstande med (Position-uafhængige eksekverbare filer) og uden PIE. Levering af CRT (C runtime) og en PIE-indlæser for statisk bundtet eksekverbare filer;
- Understøttelse af størstedelen af funktionerne i standard C-biblioteket med tilføjelser fra POSIX og nogle system-specifikke udvidelser, der er efterspurgt i eksisterende applikationer;
- Forsigtig tilgang til producent-specifikke udvidelser og deres tilføjelse kun når nødvendigt. For støtte af tredjeparts udvidelser foreslås det at anvende tilgangen fra Clang- og libc-projekterne;
- Anvendelse af bedste praksis i udviklingen ved brug af LLVM-værktøjsæt, såsom anvendelse af sanitizer og fuzzing-test fra starten.
En af de aktive udviklere af LLVM , at det giver mening at inkludere libc i LLVM-værktøjsæt, men almindeligvis, når sådan et behov opstår, bruges musl-biblioteket, som er veludviklet, understøtter forskellige arkitekturer og leverer den nødvendige funktionalitet, herunder understøttelse af dynamisk linking. Det kan være berettiget at integrere musl i LLVM og udvikle det som en fork, der er synkroniseret med det primære projekt.
Sin holdning har 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 idéer:
- At udvikle og vedligeholde en korrekt, kompatibel og high-quality Libc er en meget vanskelig opgave. Problemet ligger ikke i mængden af kode, men i at sikre korrekt adfærd og de udfordringer, der er forbundet med implementeringen af grænsefladerne, givet det enorme antal applikationer, der nogensinde er skrevet i C/C++, samt applikationer på andre sprog, hvis runtime bruger Libc. En direkte tilgang uden hensyntagen til nuancer vil blot føre til, at mange eksisterende programmer ikke vil kunne fungere sammen med Libc, og så vil et sådant projekt ikke være interessant for forbrugerne.
- Virksomhedsudvikling kan ødelægge Libc, men fremme det til bred anvendelse, hvilket vil resultere i behovet for at tilføje hacks for at sikre kompatibilitet i applikationerne. Udvikling under banneret for et virksomhedsejet open source-projekt vil trække tæppet mod virksomhedens behov og løsninger, på bekostning af fællesskabets interesser. For eksempel, når der opstår et problem forårsaget af en fejl i et andet af deres programmer, er det lettere at sikre, at Libc forbliver kompatibel med denne fejl i den kontrollerede udvikling, end at rette selve fejlen. Apple bruger en fork af BSD libc til disse formål, mens Google anvender en fork af musl i Fuchsia. Erfaringen fra musl-udvikleren viser, at de primært har været i kontakt med advokater for at afklare licensspørgsmål, men aldrig er blevet kontaktet for at afklare tekniske detaljer før ubrugelige og funktionsforstyrrende ændringer er blevet foretaget i deres forks.
- Fraværet af monokultur i udviklingen af libc og fokus på udvikling baseret på konsensusstandarder i stedet for centraliseret styring motiverer udviklere af applikationer til at anvende standarder i stedet for at binde sig til specifikke implementeringer. Det er grunden til, at forfatteren til musl er imod at inkludere sit bibliotek i LLVM, ligesom han er imod udviklingen af libc inden for LLVM, da dette ville underminere den uafhængige karakter af libc, og en bestemt implementering ville blive betragtet som første klasses løsning for LLVM, mens alle andre ville være anden klasses.
Kilde: opennet.ru
