En av utvecklarna från Google på LLVMs e-postlista om utvecklingen av ett multiplattformsstandard C-bibliotek (Libc) som en del av LLVM-projektet. Av flera anledningar är Google inte nöjda med nuvarande libc (glibc, musl) och företaget är på väg att utveckla en ny implementering, som föreslås utvecklas som en del av LLVM.
LLVM-utvecklingar har nyligen använts som grund för att bygga Googles monteringsverktyg. Huvudtanken är att om Google redan har börjat utveckla sitt libc, varför inte omedelbart utveckla sitt system som en del av LLVM, som redan erbjuder sitt eget standardbibliotek för C++ (Libc++), men inte har ett liknande standardbibliotek för C (libc).
Utvecklingen är planerad att genomföras i etapper, vilket gradvis ökar funktionaliteten. De första alternativen föreslås utformas som ett lager mellan applikationen och systemet Libc, från vilket funktioner som ännu inte har implementerats kommer att lånas. Efter att ha nått en viss funktionalitet kan den nya Libc användas som en komplett ersättning för systemet Libc. Vi planerar att börja med stöd för x86-64-arkitektur, Linux och statisk länkning (dynamisk laddning, länkning och ytterligare arkitekturer kommer att implementeras sekundärt).
Projektet är fortfarande i det inledande utvecklingsskedet, men grundläggande mål har redan definierats:
- Modularitet och utveckling i enlighet med filosofin att leverera ett granulärt bibliotek snarare än en monolitisk uppsättning;
- Stöd för statisk länkning i lägen (Positionsoberoende körbara filer) och utan PIE. Tillhandahåller CRT (C runtime) och PIE-lastare för statiskt länkade körbara filer;
- Stöd för de flesta av de vanliga C-biblioteksfunktionerna, med POSIX-tillägg och vissa systemspecifika tillägg som krävs av befintliga applikationer;
- Var försiktig med leverantörsspecifika tillägg och lägg bara till dem när det behövs. När det gäller stöd för tredjepartstillägg, föreslås det att man använder tillvägagångssättet för Clang- och libc++-projekten;
- Använda bästa praxis vid utveckling med hjälp av LLVM-verktygslådan, som att använda desinfektionsmedel och fuzz-testning från allra första början.
En av de aktiva LLVM-utvecklarna Det är tydligt att det är vettigt att skicka libc som en del av LLVM-verktygslådan, men vanligtvis, när ett sådant behov uppstår, använder de musl-biblioteket, som är välskrivet, stöder olika arkitekturer och tillhandahåller nödvändig funktionalitet, inklusive stöd för dynamiskt länkar. Det kan vara motiverat att bädda in musl i LLVM och utveckla den som en gaffel synkroniserad med huvudprojektet.
Din åsikt också Författaren till Musl-projektet, som försökte argumentera för varför Googles förslag och inkluderingen av Libc i LLVM-distributionen är mycket dåliga idéer:
- Att utveckla och underhålla en korrekt, kompatibel och högkvalitativ Libc är en mycket svår uppgift. Problemet ligger inte i mängden kod, utan i att säkerställa korrekt beteende och svårigheter med att implementera gränssnitt, med hänsyn till det enorma lagret av applikationer som någonsin skrivits i C/C++, såväl som applikationer på andra språk, vars körtid används av Libc. Ett direkt tillvägagångssätt utan att ta hänsyn till nyanserna kommer bara att leda till att många befintliga program inte kommer att kunna arbeta med Libc, men då kommer ett sådant projekt inte att vara av intresse för konsumenterna.
- Företagsutveckling kan förstöra Libc, men driva det för utbredd användning, vilket resulterar i behovet av att lägga till hacks för att säkerställa kompatibilitet i applikationer. Utveckling under överinseende av ett företagsprojekt med öppen källkod kommer att dra täcket mot företagets behov och lösningar, till skada för samhällets intressen. Till exempel, om du identifierar ett problem som orsakas av en bugg i ett annat program, är det i kontrollerad utveckling lättare att säkerställa att Libc är kompatibel med denna bugg än att fixa själva buggen. Apple använder BSD libc-gaffeln för dessa ändamål, och Google använder musl-gaffeln i Fuchsia. Erfarenheten från musl-utvecklaren är att han främst kontaktades av advokater för att klargöra licensfrågor, men han kontaktades aldrig för att klargöra tekniska detaljer innan han gjorde värdelösa och störande förändringar i sina grenar.
- Frånvaron av en monokultur i libc-utveckling och fokus på konsensusdrivna standarder snarare än individuell kontroll, vilket motiverar applikationsutvecklare att använda standarder snarare än att vara bundna till specifika implementeringar. Det är därför som författaren till musl är emot inkluderingen av sitt bibliotek i LLVM, såväl som mot utvecklingen av libc inom LLVM, eftersom i detta fall libc:s oberoende natur går förlorad och en viss implementering blir en förstklassig lösning för LLVM och alla andra blir en andra klassens lösning.
Källa: opennet.ru