Jeden z vývojářů z Google na mailing listu LLVM o vývoji multiplatformní standardní knihovny C (Libc) jako součásti projektu LLVM. Google z řady důvodů není spokojen se současnou knihovnou libc (glibc, musl) a společnost je na cestě k vývoji nové implementace, jejíž vývoj je navržen jako součást LLVM.
Vývoj LLVM byl nedávno použit jako základ pro vytváření montážních nástrojů Google. Hlavní myšlenkou je, že když Google již začal vyvíjet svou knihovnu libc, tak proč rovnou nevyvinout svůj systém v rámci LLVM, který již nabízí vlastní standardní knihovnu pro C++ (Libc++), ale nemá podobnou standardní knihovnu pro C (libc).
Vývoj je plánován na etapy s postupným zvyšováním funkčnosti. První možnosti jsou navrženy jako vrstva mezi aplikací a systémem Libc, ze které budou vypůjčeny funkce, které dosud nebyly implementovány. Po dosažení určité úrovně funkčnosti lze novou Libc použít jako kompletní náhradu za systém Libc. Plánujeme začít s podporou architektury x86-64, Linuxu a statického linkování (dynamické načítání, linkování a další architektury budou implementovány sekundárně).
Projekt je stále v počáteční fázi vývoje, ale základní cíle již byly definovány:
- Modularita a vývoj v souladu s filozofií poskytování granulární knihovny spíše než monolitické sady;
- Podpora pro statické propojení v režimech (spustitelné soubory nezávislé na pozici) a bez PIE. Poskytování CRT (C runtime) a PIE zavaděče pro staticky propojené spustitelné soubory;
- Podpora většiny standardních funkcí knihovny C, s doplňky POSIX a některými systémovými rozšířeními požadovanými stávajícími aplikacemi;
- Buďte opatrní u rozšíření specifických pro dodavatele a přidávejte je pouze v případě potřeby. Pokud jde o podporu rozšíření třetích stran, navrhuje se použít přístup projektů Clang a libc++;
- Použití osvědčených postupů při vývoji pomocí sady nástrojů LLVM, jako je použití sanitizeru a fuzz testování od samého začátku.
Jeden z aktivních vývojářů LLVM Je jasné, že má smysl dodávat libc jako součást sady nástrojů LLVM, ale obvykle, když taková potřeba nastane, použijí knihovnu musl, která je dobře napsaná, podporuje různé architektury a poskytuje potřebnou funkcionalitu, včetně podpory dynamického propojení. Může být oprávněné vložit musl do LLVM a vyvinout jej jako vidlici synchronizovanou s hlavním projektem.
Váš názor také Autor projektu Musl, který se snažil argumentovat, proč jsou návrh Googlu a zařazení Libc do distribuce LLVM velmi špatné nápady:
- Vyvinout a udržovat správnou, kompatibilní a kvalitní Libc je velmi obtížný úkol. Problém není v množství kódu, ale v zajištění správného chování a potížích při implementaci rozhraní, s přihlédnutím k obrovské vrstvě aplikací, které kdy byly napsány v C/C++, a také aplikací v jiných jazycích, jejichž runtime se používá od Libc. Přímý přístup bez zohlednění nuancí povede pouze k tomu, že mnoho stávajících programů nebude umět s Libc pracovat, ale pak takový projekt nebude pro spotřebitele zajímavý.
- Firemní vývoj může Libc zničit, ale dotlačit ji k širokému použití, což má za následek nutnost přidávat hacky, aby byla zajištěna kompatibilita v aplikacích. Vývoj pod záštitou korporátního open source projektu potáhne deku vstříc potřebám a řešením společnosti na úkor zájmů komunity. Pokud například identifikujete problém, který je způsoben chybou v jiném programu, v řízeném vývoji je snazší zajistit, aby Libc byla s touto chybou kompatibilní, než opravit chybu samotnou. Apple pro tyto účely používá BSD libc fork a Google používá musl fork ve Fuchsii. Zkušenost vývojáře musla je taková, že jej kontaktovali především právníci, aby si vyjasnili licenční problémy, ale nikdy nebyl kontaktován, aby si vyjasnil technické detaily před provedením zbytečných a rušivých změn na svých pobočkách.
- Absence monokultury ve vývoji knihovny libc a zaměření na standardy řízené konsensem spíše než na individuální kontrolu, což motivuje vývojáře aplikací k používání standardů, spíše než aby byli vázáni na konkrétní implementace. Proto je autor musl proti zahrnutí své knihovny do LLVM, stejně jako proti vývoji libc v rámci LLVM, jelikož v tomto případě se ztrácí nezávislá povaha libc a určitá implementace se stává prvotřídním řešením pro LLVM a všechny ostatní se stávají řešením druhé třídy.
Zdroj: opennet.ru