Një nga zhvilluesit e kompanisë Google në listën e postimeve të LLVM çështjen e zhvillimit të një biblioteke standarde C shumëplatformëshe (Libc) në kuadër të projektit LLVM. Për një sërë arsyesh, Google nuk është i kënaqur me libc-të aktuale (glibc, musl), dhe kompania po ecën drejt krijimit të një implementimi të ri, që propozohet të zhvillohet si pjesë e LLVM.
Zhvillimet e LLVM kohët e fundit po përdoren si bazë për ndërtimin e infrastrukturës së kompilimit të Google. Ideja kryesore është se, nëse Google tashmë ka nisur të zhvillojë libc-në e vet, atëherë pse të mos e zhvillojë menjëherë sistemin e vet si pjesë të LLVM, i cili tashmë ofron bibliotekën e vet standarde për C++ (Libc++), por nuk ka një bibliotekë standarde të ngjashme për C (Libc).
Zhvillimi planifikohet të kryhet në faza, duke shtuar gradualisht funksionalitetin. Versionet e para propozohet të realizohen si një shtresë ndërmjet aplikacionit dhe Libc së sistemit, prej së cilës do të merren veçoritë që ende nuk janë zbatuar. Pasi të arrihet një nivel i caktuar funksionaliteti, Libc e re do të mund të përdoret si zëvendësim i plotë i Libc së sistemit. Fillimisht planifikohet mbështetja për arkitekturën x86-64, Linux dhe lidhjen statike (ngarkimi dinamik, linkimi dhe arkitekturat shtesë do të zbatohen në fazën e dytë).
Projekti është ende në fazën fillestare të zhvillimit, por tashmë janë përcaktuar objektivat bazë:
- Modulariteti dhe zhvillimi në përputhje me filozofinë e ofrimit të një biblioteke të granuluar, dhe jo të një pakete monolitike;
- Mbështetje për lidhjen statike në regjimet me (Position-independent executables) dhe pa PIE. Ofrimi i CRT (C runtime) dhe ngarkuesit PIE për skedarët ekzekutues të lidhur statikisht;
- Mbështetje për pjesën më të madhe të funksioneve të bibliotekës standarde C me shtesat POSIX dhe disa zgjerime specifike për sisteme, të kërkuara nga aplikacionet ekzistuese;
- Qasje e kujdesshme ndaj zgjerimeve specifike të prodhuesve dhe shtimi i tyre vetëm kur është e nevojshme. Për mbështetjen e zgjerimeve të palëve të treta propozohet të zbatohet qasja e projekteve Clang dhe libc++;
- Përdorimi i praktikave shembullore të zhvillimit me instrumentet e LLVM, si përdorimi i sanitizer dhe testimit fuzzing që nga fillimi.
Një nga zhvilluesit aktivë të LLVM se përfshirja e libc si pjesë e paketës së mjeteve LLVM ka kuptim, por zakonisht për nevoja të tilla përdoret biblioteka musl, e cila është e shkruar me cilësi të lartë, mbështet arkitektura të ndryshme dhe ofron funksionalitetin e nevojshëm, përfshirë edhe mbështetjen për lidhje dinamike. Një qasje e arsyeshme mund të ishte integrimi i musl në LLVM dhe zhvillimi i tij si një fork i sinkronizuar me projektin kryesor.
Mendimin e tij e edhe autori i projektit Musl, i cili u përpoq të argumentonte pse propozimi i Google dhe përfshirja e Libc në paketën LLVM janë ide shumë të këqija:
- Zhvillimi dhe mirëmbajtja e një Libc të saktë, të pajtueshme dhe me cilësi të lartë është një detyrë shumë e vështirë. Problemi nuk qëndron te vëllimi i kodit, por te garantimi i sjelljes korrekte dhe te vështirësitë e zbatimit të ndërfaqeve duke pasur parasysh shtresën e madhe të aplikacioneve të shkruara ndonjëherë në C/C++, si edhe aplikacioneve në gjuhë të tjera, runtime i të cilave përdor Libc. Një qasje e drejtpërdrejtë, pa marrë parasysh nuancat, vetëm sa do të çojë në faktin që shumë programe ekzistuese nuk do të mund të punojnë me Libc, dhe në këtë rast një projekt i tillë nuk do të ishte interesant për përdoruesit.
- Zhvillimi korporativ mund ta dëmtojë Libc, por njëkohësisht ta imponojë për përdorim të gjerë, gjë që në fund do të çojë në nevojën për të shtuar hile për përputhshmëri në aplikacione. Zhvillimi nën ombrellën e një projekti të hapur korporativ do të anojë drejt nevojave dhe zgjidhjeve të kompanisë, në dëm të interesave të komunitetit. Për shembull, në rast se zbulohet një problem i shkaktuar nga një gabim në një program tjetër të vetin, në një zhvillim të kontrolluar është më e lehtë të sigurohet përputhshmëria e Libc me atë gabim sesa të korrigjohet vetë gabimi. Apple përdor për këto qëllime një fork të BSD libc, ndërsa Google përdor në Fuchsia një fork të musl. Përvoja e zhvilluesit të musl tregon se me të kanë kontaktuar kryesisht juristë për të sqaruar çështje licencimi, por kurrë nuk i janë drejtuar për të sqaruar detaje teknike përpara se të bënin në degëzimet e tyre ndryshime të padobishme dhe që prishin funksionimin.
- Mungesa e një monokulture në zhvillimin e libc dhe orientimi drejt standardeve që evoluojnë mbi bazën e konsensusit, në vend të kontrollit të njëanshëm, i nxit zhvilluesit e aplikacioneve të përdorin standardet dhe të mos lidhen me implementime të caktuara. Pikërisht për këtë arsye autori i musl kundërshton përfshirjen e kësaj biblioteke në përbërjen e LLVM, ashtu siç është kundër edhe zhvillimit të libc brenda LLVM, sepse në këtë rast humbet natyra e pavarur e libc dhe një implementim i caktuar bëhet zgjidhja e klasit të parë për LLVM, ndërsa të gjitha të tjerat mbeten të klasit të dytë.
Burimi: opennet.ru
