En av Google-utvecklarna presenterade på LLVM-postlistan ämnet för utveckling ett C-bibliotek med flera plattformar (Libc) inom ramen för LLVM-projektet.
Av olika anledningar, Google är inte nöjd med den aktuella libc (glibc, musl) och företaget är på väg att utveckla en ny implementering, som han avser att utveckla som en del av LLVM. LLVM-utvecklingen har nyligen använts som grund för att bygga Google-verktyg.
Utvecklingen planeras att ske gradvis och gradvis öka funktionaliteten. Det föreslås att de första alternativen har formen av ett mellanlager mellan applikationen och libc-systemet, från vilket de orealiserade funktionerna kommer att lånas ut.
Efter att ha nått en viss funktionsnivå kan den nya Libc användas som en komplett ersättning för Libc-systemet.
Det planeras att börja med stöd för x86-64 arkitektur, Linux och statisk bindning (dynamisk laddning, förpackning och ytterligare arkitekturer kommer att implementeras andra).
Projektet är fortfarande i det inledande utvecklingsstadiet, men de grundläggande målen har redan definierats:
- Modularitet och utveckling i enlighet med filosofin att tillhandahålla ett granulärt bibliotek, snarare än en monolitisk ensemble.
- Statiskt länkstöd i PIE-lägen (positionsoberoende körbara filer) och utan PIE. Ge CRT (C runtime) och PIE loader för statiskt länkade körbara filer.
- Stöder de flesta C-biblioteksfunktionerna standard med POSIX-plugin-program och vissa systemspecifika tillägg som begärs i befintliga applikationer.
- Noggrann inställning till specifika tillägg från leverantören och bara lägga till dem vid behov. För tilläggsstöd från tredje part föreslås det att man använder projektmetoden Clang och libc ++.
- Använda bästa praxis för utveckling med hjälp av LLVM-verktyg, såsom applicering av desinfektionsmedel och eliminering av tester från början.
En av de aktiva LLVM-utvecklarna angav det libc-leverans som en del av LLVM-verktygssatsen det är inte meningslöst, men i allmänhet med ett sådant behov använder de muslbiblioteket, Den är välskriven, stöder flera arkitekturer och ger nödvändig funktionalitet, inklusive dynamisk länkning.
Införlivandet av Musl i LLVM och dess utveckling som en synkroniserad gaffel med huvudprojektet kan motiveras.
Hans åsikt uttrycktes också av författaren till Musl-projektet, som försökte argumentera för varför Googles förslag och införandet av Libc i LLVM-leveransen är mycket dåliga idéer:
Att utveckla och underhålla rätt, kompatibel och högkvalitativ libc är en mycket svår uppgift. Problemet ligger inte i mängden kod utan i att tillhandahålla rätt beteende.
Och svårigheterna med gränssnittsimplementering, med tanke på det enorma arkivet med applikationer skrivna i C / C ++, liksom applikationer på andra språk vars körtid används av Libc.
Tillvägagångssättet mot pannan 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 ett sådant projekt kommer inte att vara av intresse för konsumenterna.
Företagsutveckling kan förstöra Libc, men kör utbredd användning, vilket kommer att resultera i behovet av att lägga till hack för att säkerställa kompatibilitet i applikationer.
Utveckling i regi av ett öppet företagsprojekt kommer att driva täckningen mot företagets behov och beslut, till nackdel för samhällets intressen.
Om du till exempel identifierar ett problem orsakat av ett fel i ett annat eget program, i utvecklingen under kontroll, är det lättare att garantera Libc's kompatibilitet med detta fel än att korrigera felet i sig.
Apple använder BSD libc-gaffeln för dessa ändamål och Google använder Fuchsia-gaffeln. Musls utvecklarerfarenhet tyder på att advokaterna kontaktade honom främst för att klargöra licensfrågorna.
Fuente: http://lists.llvm.org