Один із розробників з компанії Google у списку розсилки LLVM тему розробки багатоплатформної стандартної Бібліотеки (Libc) в рамках проекту LLVM. Через ряд причин Google не влаштовують поточні libc (glibc, musl) і компанія на шляху до розробки нової реалізації, яку пропонується розвивати як частину LLVM.
Напрацювання LLVM останнім часом використовуються як основа для побудови складального інструментарію Google. Основною ідеєю є те, що якщо Google вже почав розвивати свою libc, то чому б йому відразу не розвивати свою систему у складі LLVM, який вже пропонує свою стандартну бібліотеку для С++ (Libc++), але не має аналогічної стандартної бібліотеки для Сі ( Libc).
Розробку планується вести поетапно, поступово збільшуючи функціональність. Перші варіанти пропонується оформити у вигляді прошарку між програмою та системною Libc, з якої будуть запозичуватися ще не реалізовані можливості. Після досягнення певного рівня у функціональності нова Libc зможе застосовуватися як повна заміна системної Libc. Почати планується з підтримки архітектури x86-64, Linux та статичного зв'язування (динамічна завантаження, компонування та додаткові архітектури будуть реалізовані у другу чергу).
Проект поки що на початковій стадії розвитку, але вже визначено базові цілі:
- Модульність та розвиток відповідно до філософії постачання гранульованої бібліотеки, а не монолітного набору;
- Підтримка статичного зв'язування у режимах з (Position-independent executables) і без PIE. Надання CRT (C runtime) та завантажувача PIE для статично зв'язуваних виконуваних файлів;
- Підтримка більшої частини функцій стандартної Сі-бібліотеки з доповненнями POSIX та деякими специфічними для систем розширеннями, потрібними в існуючих додатках;
- Обережне ставлення до специфічних для виробників розширень та їх додавання лише за необхідності. Щодо підтримки сторонніх розширень пропонується застосовувати підхід проектів Clang та libc++;
- Використання зразкових практик у розробці з використанням інструментарію LLVM, таких як застосування sanitizer та fuzzing-тестування із самого початку.
Один із активних розробників LLVM , Що постачання libc у складі інструментарію LLVM не позбавлене сенсу, але зазвичай при подібній необхідності використовують бібліотеку musl, яка якісно написана, підтримує різні архітектури та надає необхідну функціональність, у тому числі підтримує динамічне зв'язування. Виправданим може бути вбудовування musl у LLVM та розвиток його як синхронізованого з основним проектом форка.
Своя думка також автор проекту Musl, який спробував аргументувати чому пропозиція Google та включення Libc у постачання LLVM є дуже поганими ідеями:
- Розробка та супровід коректної, сумісної та високоякісної Libc є дуже важким завданням. Проблема над обсягом коду, а забезпеченні коректного поведінки і труднощі з реалізацією інтерфейсів з урахуванням величезного пласта коли-небудь написаних додатків на С/C++, і навіть додатків іншими мовами, runtime яких використовує Libc. Підхід у лоб без урахування нюансів лише призведе до того, що багато існуючих програм не зможуть працювати з Libc, але тоді такий проект не буде цікавий споживачам.
- Корпоративна технологія може зіпсувати Libc, але проштовхнути для широкого використання, результатом чого стане необхідність додавання хаків для забезпечення сумісності додатків. Розробка під егідою корпоративного відкритого проекту тягтиме ковдру у бік потреб та рішень компанії, на шкоду інтересам спільноти. Наприклад, у разі виявлення проблеми, яка викликана помилкою в іншій своїй програмі, у підконтрольній розробці простіше забезпечити сумісність Libc із цією помилкою, ніж виправити саму помилку. Apple використовує для цього форк BSD libc, а Google застосовує в Fuchsia форк musl. Досвід розробника musl говорить про те, що з ним пов'язувалися здебільшого юристи для уточнення питань ліцензування, але ніколи не зверталися для уточнення технічних деталей перед внесенням до своїх відгалужень змін, що марних і порушують роботу.
- Відсутність монокультури при розробці libc і орієнтація на стандарти, що розвиваються на основі досягнення консенсусу, замість одноосібного управління, що мотивує розробників прикладних додатків використовувати стандарти, а не прив'язуватися до конкретних реалізацій. Саме тому автор musl проти включення його бібліотеки до складу LLVM, як і проти розробки libc у рамках LLVM, тому що в цьому випадку втрачається незалежний характер libc і певна реалізація стає рішенням першого класу для LLVM, а решта — другого.
Джерело: opennet.ru