Един от разработчиците на компанията 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 и статично свързване (динамичното зареждане, комбиниране и допълнителните архитектури ще бъдат реализирани на второ място).
Проектът все още е в начален етап на развитие, но вече са определени основните цели:
- Модулност и развитие в съответствие с философията на предоставяне на гранулирана библиотека, а не монолитен набор;
- Поддръжка на статично свързване в режимите с (Position-independent executables) и без PIE. Предоставяне на CRT (C runtime) и зареждач PIE за статично свързани изпълними файлове;
- Поддръжка на по-голямата част от функциите на стандартната C-библиотека с допълнения POSIX и някои специфични за системата разширения, търсени в съществуващите приложения;
- Внимателно отношение към специфичните за производителите разширения и добавянето им едва при необходимост. Що се отнася до поддръжката на външни разширения, се предлага да се прилага подхода на проектите Clang и libc++;
- Използване на добри практики в разработката с помощта на инструментариум LLVM, като използването на синтактични проверки и тестове с размазване от самото начало.
Един от активните разработчици на LLVM , че доставката на libc като част от инструментариума на LLVM не е безсмислена, но обикновено при подобна необходимост се използва библиотеката musl, която е качествено написана, поддържа различни архитектури и предоставя необходимата функционалност, включително поддръжка на динамично свързване. Оправдано може да бъде вграждането на musl в LLVM и развитието му като синхронизирано с основния проект клонинг.
Своето мнение също авторът на проекта Musl, който се опита да аргументира защо предложението на Google и включването на Libc в доставката на LLVM са много лоши идеи:
- Разработката и поддръжката на коректна, съвместима и висококачествена Libc е много трудна задача. Проблемът не е в обема на кода, а в осигуряването на правилно поведение и трудностите при реализирането на интерфейси, имайки предвид огромния брой написани приложения на C/C++, както и приложения на други езици, чийто runtime използва Libc. Подходът на сляпо без да се вземат предвид нюансите просто ще доведе до това, че много съществуващи програми няма да могат да работят с Libc, а такъв проект няма да бъде интересен за потребителите.
- Корпоративната разработка може да развали Libc, но да бъде пробутана за широко използване, в резултат на което ще се наложи добавянето на хакове за осигуряване на съвместимост в приложенията. Разработката под егидата на корпоративен отворен проект ще изтегля одеялото към нуждите и решенията на компанията, в ущърб на интересите на общността. Например, в случай на откритие на проблем, който е предизвикан от грешка в друга своя програма, в контекста на контролирана разработка е по-лесно да се осигури съвместимост на Libc с тази грешка, отколкото да се поправи самата грешка. Apple използва за тези цели клонинг на BSD libc, а Google прилага в Fuchsia клонинг на musl. Опитът на разработчика на musl показва, че с него основно са се свързвали юристи за уточняване на въпроси свързани с лицензиране, но никога не са се обръщали за уточняване на технически детайли преди въвеждането на своите разклонения на безполезни и нарушаващи работата изменения.
- Отсъствието на монокултура при разработването на libc и ориентирането към стандарти, развити въз основа на постигането на съгласие, вместо централизирано управление, мотивира разработчиците на приложения да използват тези стандарти, а не да се привързват към конкретни реализации. Именно затова авторът на musl е против включването на библиотеката си в състава на LLVM, както и против разработването на libc в рамките на LLVM, тъй като в този случай се губи независимият характер на libc и определена реализация става решение от първи клас за LLVM, а всички останали – от втори.
Източник: opennet.ru
