Az egyik fejlesztő a Google-tól az LLVM levelezőlistán egy többplatformos szabványos C könyvtár (Libc) fejlesztéséről az LLVM projekt részeként. A Google több okból sem elégedett a jelenlegi libc-vel (glibc, musl), és a cég egy új implementáció kidolgozása felé tart, amelyet az LLVM részeként javasolnak kifejleszteni.
Az LLVM fejlesztések a közelmúltban a Google összeszerelő eszközeinek kiépítésének alapjául szolgáltak. A fő gondolat az, hogy ha a Google már elkezdte fejleszteni a libc-jét, akkor miért ne fejlesztené azonnal a rendszerét az LLVM részeként, amely már kínál saját szabványos könyvtárat C++-hoz (Libc++), de nincs hasonló szabványos könyvtára C-hez. (libc).
A fejlesztést a tervek szerint szakaszosan hajtják végre, fokozatosan növelve a funkcionalitást. Az első opciókat az alkalmazás és a Libc rendszer közötti rétegként javasoljuk kialakítani, amelyből a még nem implementált funkciókat kölcsönözzük. Egy bizonyos funkcionalitási szint elérése után az új Libc használható a Libc rendszer teljes helyettesítésére. Terveink szerint az x86-64 architektúra, a Linux és a statikus linkelés támogatásával kezdjük (másodlagosan a dinamikus betöltés, linkelés és további architektúrák 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, összhangban a szemcsés könyvtár szállításának filozófiájával, nem pedig egy monolitikus készlettel;
- A statikus összekapcsolás támogatása módokban (Pozíciófüggetlen végrehajtható fájlok) és PIE nélkül. CRT (C futásidejű) és PIE betöltő biztosítása statikusan csatolt végrehajtható fájlok számára;
- Támogatja a legtöbb szabványos C-könyvtár funkciót, POSIX-kiegészítésekkel és néhány rendszerspecifikus kiterjesztéssel, amelyet a meglévő alkalmazások igényelnek;
- Legyen óvatos a szállítóspecifikus bővítményekkel, és csak szükség esetén adja hozzá őket. A harmadik féltől származó bővítmények támogatását illetően a Clang és a libc++ projektek megközelítése javasolt;
- A legjobb gyakorlatok alkalmazása a fejlesztés során az LLVM eszközkészlet használatával, például a fertőtlenítő és a fuzz tesztelése a kezdetektől fogva.
Az egyik aktív LLVM fejlesztő Nyilvánvaló, hogy van értelme a libc-t az LLVM eszközkészlet részeként szállítani, de általában, ha erre szükség van, a musl könyvtárat használják, amely jól meg van írva, támogatja a különböző architektúrákat és biztosítja a szükséges funkcionalitást, beleértve a dinamikus támogatást is. linkelés. Indokolt lehet a musl beágyazása az LLVM-be, és a főprojekttel szinkronizált villaként fejleszteni.
A te véleményed is A Musl projekt szerzője, aki azzal próbált érvelni, hogy a Google javaslata és a Libc beemelése az LLVM disztribúcióba 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észek megvalósításának nehézségeiben, figyelembe véve a valaha C/C++ nyelven írt alkalmazások hatalmas rétegét, valamint a más nyelvű alkalmazásokat, amelyek futásidejét használják ki. szerző: Libc. Az árnyalatok figyelembe vétele nélküli közvetlen megközelítés csak azt eredményezi, hogy sok meglévő program nem fog működni a Libc-vel, de akkor egy ilyen projekt nem lesz érdekes a fogyasztók számára.
- A vállalati fejlesztések tönkretehetik a Libc-et, de széles körben elterjedt használatba kényszeríthetik, aminek következtében feltörésekre van szükség az alkalmazások kompatibilitása érdekében. A vállalati nyílt forráskódú projekt égisze alatt történő fejlesztés a vállalat igényei és megoldásai felé húzza a takarót, a közösség érdekeinek rovására. Például, ha olyan problémát azonosít, amelyet egy másik program hibája okoz, az ellenőrzött fejlesztés során könnyebb meggyőződni arról, hogy a Libc kompatibilis-e 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 musl villát fuksziában. A muszli fejlesztő tapasztalata az, hogy főként jogászok keresték meg, hogy tisztázzák az engedélyezési kérdéseket, de soha nem keresték meg technikai részletek tisztázása érdekében, mielőtt haszontalan és zavaró változtatásokat hajtottak végre fiókjaiban.
- A monokultúra hiánya a libc fejlesztésben, és a konszenzus-vezérelt szabványokra való összpontosítás az egyéni vezérlés helyett, ami arra ösztönzi az alkalmazásfejlesztőket, hogy szabványokat használjanak, ahelyett, hogy konkrét megvalósításokhoz kötődnének. Éppen ezért a musl szerzője ellenzi könyvtárának LLVM-be való felvételét, valamint a libc LLVM-en belüli fejlesztését, mivel ebben az esetben a libc függetlensége elvész, és egy bizonyos implementáció első osztályú megoldássá válik Az LLVM és az összes többi másodosztályú megoldássá válik.
Forrás: opennet.ru