Один из разработчиков из компании Google поднял в списке рассылки LLVM тему разработки многоплатформенной стандартной Си-библиотеки (Libc) в рамках проекта LLVM. По ряду причин Google не устраивают текущие libc (glibc, musl) и компания на пути к разработке новой реализации, которую предлагается развивать как часть LLVM.

Наработки LLVM последнее время используются в качестве основы для построения сборочного инструментария Google. Основной идеей является то, что если Google уже начал развивать свою libc, то почему бы ему сразу не развивать свою систему в составе LLVM, который уже предлагает свою стандартную библиотеку для С++ (Libc++), но не имеет аналогичной стандартной библиотеки для Си (Libc).

Разработку планируется вести поэтапно, постепенно наращивая функциональность. Первые варианты предлагается оформить в виде прослойки между приложением и системной Libc, из которой будут заимствоваться ещё не реализованные возможности. После достижения определённого уровня в функциональности новая Libc сможет применяться в качестве полной замены системной Libc. Начать планируется с поддержки архитектуры x86-64, Linux и статического связывания (динамическая загрузка, компоновка и дополнительные архитектуры будут реализованы во вторую очередь).

Проект пока на начальной стадии развития, но уже определены базовые цели:

• Модульность и развитие в соответствии с философией поставки гранулированной библиотеки, а не монолитного набора;
• Поддержка статического связывания в режимах с PIE (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, а все остальные - второго.