Един от разработчиците от 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 loader за статично свързани изпълними файлове;
- Поддръжка за повечето от стандартните функции на C библиотеката, с POSIX добавки и някои специфични за системата разширения, изисквани от съществуващите приложения;
- Бъдете внимателни с разширенията, специфични за доставчика, и ги добавяйте само когато е необходимо. Що се отнася до поддръжката на разширения на трети страни, предлага се да се използва подходът на проектите Clang и libc++;
- Използване на най-добри практики в разработката с помощта на инструментариума LLVM, като например използване на дезинфектант и тестване на мъх от самото начало.
Един от активните разработчици на LLVM Ясно е, че има смисъл да се доставя libc като част от инструментариума на LLVM, но обикновено, когато възникне такава необходимост, те използват библиотеката musl, която е добре написана, поддържа различни архитектури и предоставя необходимата функционалност, включително поддръжка за динамични свързване. Може да е оправдано да се вгради musl в LLVM и да се развие като разклонение, синхронизирано с основния проект.
Вашето мнение също Авторът на проекта Musl, който се опита да аргументира защо предложението на Google и включването на Libc в дистрибуцията на LLVM са много лоши идеи:
- Разработването и поддържането на правилен, съвместим и висококачествен Libc е много трудна задача. Проблемът не е в количеството код, а в осигуряването на правилно поведение и трудности при внедряването на интерфейси, като се има предвид огромният слой от приложения, писани някога на C/C++, както и приложения на други езици, чието време за изпълнение се използва от Libc. Челният подход, без да се вземат предвид нюансите, ще доведе само до факта, че много съществуващи програми няма да могат да работят с Libc, но тогава такъв проект няма да представлява интерес за потребителите.
- Корпоративното развитие може да съсипе Libc, но да го накара да се използва широко, което води до необходимостта от добавяне на хакове, за да се осигури съвместимост в приложенията. Разработката под егидата на корпоративен проект с отворен код ще дръпне одеялото към нуждите и решенията на компанията, в ущърб на интересите на общността. Например, ако идентифицирате проблем, който е причинен от грешка в друга програма, при контролирана разработка е по-лесно да се гарантира, че Libc е съвместим с тази грешка, отколкото да коригирате самата грешка. Apple използва BSD libc fork за тези цели, а Google използва musl fork във Fuchsia. Опитът на разработчика на musl е, че с него са се свързвали предимно адвокати, за да изяснят проблемите с лицензирането, но никога не е бил потърсен, за да изясни технически подробности, преди да направи безполезни и разрушителни промени в своите клонове.
- Липсата на монокултура в разработката на libc и фокус върху стандарти, основани на консенсус, а не върху индивидуален контрол, което мотивира разработчиците на приложения да използват стандарти, вместо да бъдат обвързани с конкретни реализации. Ето защо авторът на musl е против включването на неговата библиотека в LLVM, както и против развитието на libc в рамките на LLVM, тъй като в този случай се губи независимата природа на libc и определена имплементация се превръща в първокласно решение за LLVM, а всички останали стават второкласно решение.
Източник: opennet.ru