A Google egyik fejlesztője bemutatta az LLVM levelezőlistán a fejlesztés témáját cross-platform szabványos C könyvtár (Libc) az LLVM projekt keretében.
Számos ok miatt, A Google nem elégedett a jelenlegi libc-vel (glibc, muszlim) és a vállalat jó úton halad új megvalósítás kifejlesztése érdekében, amelyet az LLVM részeként kíván fejleszteni. Az LLVM fejlesztéseit a közelmúltban használták a Google eszközök felépítésének alapjául.
A fejlesztés a tervek szerint fokozatos lesz, fokozatosan növelve a funkcionalitást. Javasoljuk, hogy az első lehetőségek az alkalmazás és a libc rendszer között egy közbenső réteg formájában történjenek, amelyből a nem realizált tulajdonságokat kölcsönzik.
Miután elérte a funkcionalitás bizonyos szintjét, az új Libc a Libc rendszer teljes cseréjeként használható.
A tervek szerint az x86-64 architektúra, a Linux és a statikus összerendelés támogatásával kezdődik (dinamikus betöltés, csomagolás és további architektúrák másodikként kerülnek megvalósításra).
A projekt még a fejlesztés kezdeti szakaszában van, de az alapvető célokat már meghatározták:
- Modularitás és fejlesztés a szemcsés könyvtár ellátásának filozófiájával összhangban, nem pedig monolit együttes.
- Statikus kapcsolat támogatás PIE módokban (pozíciótól független futtatható fájlok) és PIE nélkül. CRT (C futásidejű) és PIE betöltőt biztosít a statikusan összekapcsolt futtatható fájlokhoz.
- Támogatja a legtöbb C könyvtár funkciót szabványos POSIX beépülő modulokkal és néhány rendszer-specifikus kiterjesztéssel, amelyeket a meglévő alkalmazások igényelnek.
- Óvatos hozzáállás az egyes kiterjesztésekhez a szolgáltatótól, és csak szükség esetén adja hozzá őket. Harmadik féltől származó kiterjesztés támogatásához javasoljuk a Clang és a libc ++ projekt megközelítés használatát.
- A fejlesztési bevált gyakorlatok használata az LLVM eszközök használatával, mint például a fertőtlenítőszerek alkalmazása és a tesztek kezdettől való megszüntetése.
Az egyik aktív LLVM fejlesztő ezt jelezte libc kézbesítés az LLVM eszköztár részeként nincs értelme, de általában ilyen igény mellett használják a musl könyvtárat, Jól meg van írva, több architektúrát támogat és biztosítja a szükséges funkciókat, beleértve a dinamikus összekapcsolást is.
Indokolható a Musl beépítése az LLVM-be és szinkronizált villaként való fejlesztése a fő projekttel.
Véleményét a Musl projekt szerzője is hangoztatta, és megpróbálta érvelni azzal, hogy a Google javaslata és a Libc szerepeltetése az LLVM szolgáltatásban miért nagyon rossz ötlet:
A helyes, kompatibilis és jó minőségű libc fejlesztése és fenntartása nagyon nehéz feladat. A probléma nem a kód mennyiségében van, hanem a helyes viselkedés biztosításában.
És az interfész megvalósításának nehézségei, figyelembe véve a C / C ++ nyelven írt alkalmazások hatalmas tárházát, valamint más nyelvű alkalmazásokat, amelyek futási idejét a Libc használja.
A homlok megközelítése az árnyalatok figyelembevétele nélkül csak ahhoz vezet, hogy számos létező program nem lesz képes együttműködni a Libc-szel, de egy ilyen projekt nem fogja érdekelni a fogyasztókat.
A vállalati fejlődés tönkreteheti Libc-t, de elterjedt a használat, aminek következtében szükség lesz feltörésekre az alkalmazások kompatibilitásának biztosítása érdekében.
A nyílt vállalati projekt égisze alatt zajló fejlesztés a társaság igényeinek és döntéseinek irányába tereli a lefedettséget, a közösség érdekeinek rovására.
Például egy másik saját program hibája által okozott probléma azonosítása esetén, az ellenőrzés alatt álló fejlesztésnél könnyebb garantálni a Libc kompatibilitását ezzel a hibával, mint magát a hibát kijavítani.
Az Apple a BSD libc villát használja erre a célra, a Google pedig a fukszia villát. Musl fejlesztői tapasztalatai azt sugallják, hogy az ügyvédek elsősorban az engedélyezési kérdések tisztázása érdekében keresték meg őt.
forrás: http://lists.llvm.org