Един от разработчиците на Google представи темата за разработване в пощенския списък на LLVM междуплатформена стандартна библиотека C (Libc) в рамките на проекта LLVM.
По няколко причини, Google не е доволен от текущия libc (glibc, musl) и компанията е на път да разработи ново изпълнение, която възнамерява да разработи като част от LLVM. LLVM разработките напоследък се използват като основа за изграждане на инструменти на Google.
Планира се развитието да бъде постепенно, постепенно увеличавайки функционалността. Предлага се първите опции да бъдат под формата на междинен слой между приложението и системата libc, от който ще бъдат заимствани нереализираните функции.
След достигане на определено ниво на функционалност, новият Libc може да се използва като пълен заместител на системата Libc.
Планира се да започне с поддръжка на архитектурата x86-64, Linux и статично свързване (динамично зареждане, опаковане и допълнителни архитектури ще бъдат внедрени на второ място).
Проектът все още е в начален етап на развитие, но основните цели вече са дефинирани:
- Модулност и развитие в съответствие с философията за предоставяне на гранулирана библиотека, а не монолитен ансамбъл.
- Поддръжка на статична връзка в режими PIE (независими от позицията изпълними файлове) и без PIE. Осигурете CRT (C Runtime) и PIE loader за статично свързани изпълними файлове.
- Поддържа повечето функции на библиотеката C стандартно с приставки POSIX и някои специфични за системата разширения, които се изискват в съществуващи приложения.
- Внимателно отношение към конкретни разширения от доставчика и да ги добавяте само когато е необходимо. За поддръжка на разширения на трети страни се предлага използването на проектния подход Clang и libc ++.
- Използване на най-добрите практики в разработването с помощта на LLVM Tools, като прилагането на дезинфектанти и премахването на тестове от самото начало.
Един от активните разработчици на LLVM посочи това libc доставка като част от LLVM инструментариум не е без значение, но като цяло с такава нужда те използват musl библиотеката, Той е добре написан, поддържа множество архитектури и осигурява необходимата функционалност, включително динамично свързване.
Включването на Musl в LLVM и развитието му като синхронизирана вилка с основния проект може да бъде оправдано.
Мнението му беше изразено и от автора на проекта Musl, който се опита да аргументира защо предложението на Google и включването на Libc в доставката на LLVM са много лоши идеи:
Разработването и поддържането на правилния, съвместим и висококачествен libc е много трудна задача. Проблемът не е в количеството код, а в осигуряването на правилното поведение.
И трудностите с внедряването на интерфейса, като се има предвид огромното хранилище на приложения, написани на C / C ++, както и приложения на други езици, чието изпълнение се използва от Libc.
Подходът към челото, без да се вземат предвид нюансите, ще доведе само до факта, че много съществуващи програми няма да могат да работят с Libc, но такъв проект няма да представлява интерес за потребителите.
Корпоративното развитие може да съсипе Libc, но стимулират широкото използване, което ще доведе до необходимостта от добавяне на хакове, за да се осигури съвместимост в приложенията.
Развитието под егидата на отворен корпоративен проект ще насочи покритието към нуждите и решенията на компанията, в ущърб на интересите на общността.
Например, в случай на идентифициране на проблем, причинен от грешка в друга ваша програма, в разработката под контрол е по-лесно да се гарантира съвместимостта на Libc с тази грешка, отколкото да се коригира самата грешка.
Apple използва вилицата BSD libc за тези цели, а Google използва вилицата Fuchsia. Опитът на разработчиците на Musl предполага, че адвокатите са се свързали с него предимно за изясняване на проблемите с лицензирането.
Fuente: http://lists.llvm.org