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