Jeden z vývojářů společnosti Google v mailing listu LLVM téma vývoje multiplatformní standardní knihovny C (Libc) v rámci projektu LLVM. Z několika důvodů není Google spokojen s aktuálními libc (glibc, musl) a společnost se chystá vyvinout novou implementaci, kterou navrhuje rozvíjet jako součást LLVM.
Návrhy LLVM byly v poslední době používány jako základ pro konstrukci nástrojů Google. Hlavní myšlenkou je, že pokud Google už začal vyvíjet svou libc, proč by rovnou neměl vyvíjet svůj systém v rámci LLVM, který již nabízí svou standardní knihovnu pro C++ (Libc++), ale nemá ekvivalentní standardní knihovnu pro C (Libc).
Vývoj se plánuje realizovat postupně, s postupným zvyšováním funkčnosti. První varianty by měly být navrženy jako mezivrstva mezi aplikací a systémovou Libc, z níž budou přebírány ještě neimplementované funkce. Po dosažení určité úrovně funkčnosti by nová Libc mohla být použita jako plná náhrada systémové Libc. Plánuje se začít s podporou architektury x86-64, Linux a statického linkování (dynamické načítání, sestavení a další architektury budou implementovány jako druhé).
Projekt je zatím v počáteční fázi vývoje, ale již byly stanoveny základní cíle:
- Modularita a vývoj v souladu s filozofií dodávky granularní knihovny, místo monolitického balíku;
- Podpora statického linkování v režimech s (pozice-nezávislé spustitelné soubory) a bez PIE. Poskytnutí CRT (C runtime) a načítače PIE pro staticky linkované spustitelné soubory;
- Podpora většiny funkcí standardní C knihovny s dodatky POSIX a některými specifickými rozšířeními pro systémy, které jsou vyžadovány v existujících aplikacích;
- Obezřetný přístup k rozšířením specifickým pro výrobce s jejich přidáváním pouze v případě potřeby. V oblasti podpory externích rozšíření se navrhuje použít přístup projektů Clang a libc++;
- Používání osvědčených praktik při vývoji s využitím nástrojů LLVM, jako jsou aplikace sanitizer a fuzzing testování od samého začátku.
Jeden z aktivních vývojářů LLVM , že dodávka libc jako součástí nástrojového řetězce LLVM není bezvýznamná, ale obvykle, když je taková potřeba, se používá knihovna musl, která je kvalitně napsaná, podporuje různé architektury a poskytuje potřebnou funkcionalitu, včetně podpory dynamického propojování. Integrace musl do LLVM a jeho rozvoj jako synchronizované větve hlavního projektu může být oprávněná.
Své názory také autor projektu Musl, který se pokusil argumentovat, proč navrhované Google a zahrnutí Libc do dodávky LLVM jsou velmi špatné nápady:
- Vývoj a údržba korektní, kompatibilní a vysoce kvalitní Libc je velmi obtížný úkol. Problém nespočívá v objemu kódu, ale v zajištění správného chování a v potížích s implementací rozhraní s ohledem na obrovské množství někdy napsaných aplikací v C/C++, jakož i aplikací v jiných jazycích, jejichž runtime používá Libc. Přístup bez ohledu na nuance povede pouze k tomu, že mnohé existující programy nebudou schopné pracovat s Libc, což takový projekt učiní nezajímavým pro spotřebitele.
- Korporátní vývoj může zkazit Libc, ale prosadit ji k širokému použití, čímž se stane nutností přidávat hacky pro zajištění kompatibility v aplikacích. Vývoj pod egidou korporátního otevřeného projektu bude táhnout deku směrem k potřebám a řešením firmy na úkor zájmů komunity. Například v případě zjištění problému, který je způsoben chybou v jinej své aplikaci, v kontrolovaném vývoji je snazší zajistit kompatibilitu Libc s touto chybou, než opravit samotnou chybu. Apple pro tyto účely využívá fork BSD libc, zatímco Google používá ve Fuchsia fork musl. Zkušenost vývojáře musl ukazuje, že s ním se většinou spojovali právníci, aby objasnili otázky týkající se licencování, ale nikdy se neptali na technické detaily před zapracováním do svých větví bezcenných a zhoršujících funkčnost změn.
- Absence of monoculture in the development of libc and focus on standards based on consensus rather than unilateral control motivates application developers to use standards instead of tying themselves to specific implementations. This is why the author of musl is against including his library in LLVM, as well as against the development of libc within LLVM, because in this case, the independent nature of libc would be lost, and a particular implementation would become a first-class solution for LLVM, while all others would be second-class.
Zdroj: opennet.ru
