Один із розробників Google представив у списку розсилки LLVM тему розробки крос-платформна стандартна бібліотека C. (Libc) в рамках проекту LLVM.
З кількох причин Google не задоволений поточним libc (glibc, musl) і компанія йде на шлях розробки нової реалізації, який він має намір розробити в рамках LLVM. Розробки LLVM нещодавно стали основою для створення інструментів Google.
Розробка планується поступова, поступово збільшуючи функціональність. Запропоновано, щоб перші варіанти мали форму проміжного шару між додатком та системою libc, з якого будуть запозичені нереалізовані функції.
Після досягнення певного рівня функціональності, новий Libc можна використовувати як повну заміну системі Libc.
Планується почати з підтримки архітектури x86-64, Linux та статичного прив'язки (динамічне завантаження, упаковка та додаткові архітектури будуть реалізовані другими).
Проект все ще перебуває на початковій стадії розробки, але основні цілі вже визначені:
- Модульність та розвиток відповідно до філософії постачання гранульованої бібліотеки, а не монолітний ансамбль.
- Підтримка статичного зв'язку в режимах PIE (незалежні від позиції виконувані файли) і без PIE. Надайте CRT (C Runtime) та завантажувач PIE для статично пов’язаних виконуваних файлів.
- Підтримує більшість функцій бібліотеки 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, а Google - вилку Fuchsia. Досвід розробника Мусла свідчить про те, що адвокати зв’язувались з ним насамперед для з’ясування питань ліцензування.
Фуенте: http://lists.llvm.org