Програмерите од Google предложија да развијат сопствен libc за LLVM

Еден од програмерите од Google подигнат на LLVM мејлинг листата за развој на мултиплатформска стандардна C библиотека (Libc) како дел од проектот LLVM. Од повеќе причини, Google не е задоволен од актуелниот libc (glibc, musl) и компанијата е на пат да развие нова имплементација, која се предлага да се развива како дел од LLVM.

Развојот на LLVM неодамна се користи како основа за градење на алатките за склопување на Google. Главната идеја е дека ако Google веќе почна да го развива својот libc, тогаш зошто веднаш да не го развие својот систем како дел од LLVM, кој веќе нуди своја стандардна библиотека за C++ (Libc++), но нема слична стандардна библиотека за C (libc).

Развојот се планира да се врши во фази, постепено зголемувајќи ја функционалноста. Првите опции се предлагаат да бидат дизајнирани како слој помеѓу апликацијата и системот Libc, од кој ќе бидат позајмени карактеристики кои сè уште не се имплементирани. По постигнување на одредено ниво на функционалност, новиот Libc може да се користи како целосна замена за системот Libc. Планираме да започнеме со поддршка за x86-64 архитектура, Linux и статичко поврзување (динамично вчитување, поврзување и дополнителни архитектури ќе се имплементираат секундарно).

Проектот се уште е во почетна фаза на развој, но веќе се дефинирани основните цели:

• Модуларност и развој во согласност со филозофијата на испорака на зрнести библиотека наместо монолитен сет;
• Поддршка за статичко поврзување во режими со Пита (Позиционо-независни извршни датотеки) и без PIE. Обезбедување CRT (C runtime) и PIE подигнувач за статички поврзани извршни датотеки;
• Поддршка за повеќето од стандардните функции на библиотеката C, со дополнувања на POSIX и некои проширувања специфични за системот што ги бараат постоечките апликации;
• Бидете внимателни со екстензии специфични за продавачот и додавајте ги само кога е потребно. Во однос на поддршката за екстензии од трети страни, се предлага да се користи пристапот на проектите Clang и libc++;
• Користење на најдобрите практики во развојот со помош на прирачникот за алатки LLVM, како што е употребата на средства за дезинфекција и fuzz тестирање од самиот почеток.

Еден од активните развивачи на LLVM истакнаЈасно е дека има смисла да се испорача libc како дел од пакетот алатки LLVM, но обично, кога ќе се појави таква потреба, тие ја користат библиотеката musl, која е добро напишана, поддржува различни архитектури и ја обезбедува потребната функционалност, вклучително и поддршка за динамички поврзување. Можеби е оправдано да се вгради musl во LLVM и да се развие како вилушка синхронизирана со главниот проект.

Ваше мислење исто така изразени Авторот на проектот Musl, кој се обиде да аргументира зошто предлогот на Google и вклучувањето на Libc во дистрибуцијата LLVM се многу лоши идеи:

• Развивањето и одржувањето на правилен, компатибилен и висококвалитетен Libc е многу тешка задача. Проблемот не е во количината на кодот, туку во обезбедувањето правилно однесување и тешкотии во имплементацијата на интерфејси, земајќи го предвид огромниот слој на апликации напишани во C/C++, како и апликациите на други јазици, чие време на работа се користи од Libc. Директен пристап без да се земат предвид нијансите само ќе доведе до фактот дека многу постоечки програми нема да можат да работат со Libc, но тогаш таков проект нема да биде од интерес за потрошувачите.
• Корпоративниот развој може да го уништи Libc, но го турка во широка употреба, што резултира со потреба од додавање хакови за да се обезбеди компатибилност во апликациите. Развојот под покровителство на корпоративен проект со отворен код ќе го повлече ќебето кон потребите и решенијата на компанијата, на штета на интересите на заедницата. На пример, ако идентификувате проблем што е предизвикан од грешка во друга програма, во контролираниот развој полесно е да се осигурате дека Libc е компатибилен со оваа грешка отколку да се поправи самата грешка. Apple ја користи вилушката BSD libc за овие цели, а Google ја користи вилушката musl во обичка. Искуството на развивачот на musl е дека тој бил контактиран главно од адвокати за да се разјаснат прашањата за лиценцирање, но никогаш не бил контактиран за да се разјаснат техничките детали пред да се направат бескорисни и вознемирувачки промени во неговите филијали.
• Отсуството на монокултура во развојот на libc и фокусирање на стандарди водени од консензус наместо индивидуална контрола, што ги мотивира развивачите на апликации да користат стандарди наместо да се врзуваат за специфични имплементации. Затоа авторот на musl е против вклучувањето на неговата библиотека во LLVM, како и против развојот на libc во рамките на LLVM, бидејќи во овој случај се губи независната природа на libc и одредена имплементација станува првокласно решение за LLVM, и сите други стануваат решение од втора класа.

Извор: opennet.ru