Один из разработчиков Google представил в списке рассылки LLVM тему разработки кроссплатформенная стандартная библиотека C (Libc) в рамках проекта LLVM.
По нескольким причинам, Google не удовлетворен текущим libc (glibc, мусл) и компания находится на пути к разработке новой реализации, которую он намерен развивать в рамках LLVM. Разработки LLVM недавно были использованы в качестве основы для создания инструментов Google.
Развитие планируется постепенно, постепенно увеличивая функциональность. Первые варианты предлагается сделать в виде промежуточного слоя между приложением и системой libc, из которого будут заимствованы нереализованные функции.
После достижения определенного уровня функциональности новый Libc можно использовать как полную замену системе Libc.
Планируется начать с поддержки архитектуры x86-64, Linux и статической привязки (во-вторых, будут реализованы динамическая загрузка, упаковка и дополнительные архитектуры).
Проект все еще находится на начальной стадии разработки, но основные цели уже определены:
- Модульность и развитие в соответствии с философией предоставления гранулярной библиотеки, а не монолитный ансамбль.
- Поддержка статических ссылок в режимах PIE (независимые от позиции исполняемые файлы) и без PIE. Предоставьте CRT (среда выполнения C) и загрузчик 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