ProHoster > Блог > ozi ịntanetị > Ndị mmepe sitere na Google tụrụ aro ka ha mepụta libc nke ha maka LLVM
Ndị mmepe sitere na Google tụrụ aro ka ha mepụta libc nke ha maka LLVM
Один из разработчиков из компании Google ewelitere в списке рассылки LLVM тему разработки многоплатформенной стандартной Си-библиотеки (Libc) в рамках проекта LLVM. По ряду причин Google не устраивают текущие libc (glibc, musl) и компания на пути к разработке новой реализации, которую предлагается развивать как часть LLVM.
Наработки LLVM последнее время используются в качестве основы для построения сборочного инструментария Google. Основной идеей является то, что если Google уже начал развивать свою libc, то почему бы ему сразу не развивать свою систему в составе LLVM, который уже предлагает свою стандартную библиотеку для С++ (Libc++), но не имеет аналогичной стандартной библиотеки для Си (Libc).
Разработку планируется вести поэтапно, постепенно наращивая функциональность. Первые варианты предлагается оформить в виде прослойки между приложением и системной Libc, из которой будут заимствоваться ещё не реализованные возможности. После достижения определённого уровня в функциональности новая Libc сможет применяться в качестве полной замены системной Libc. Начать планируется с поддержки архитектуры x86-64, Linux и статического связывания (динамическая загрузка, компоновка и дополнительные архитектуры будут реализованы во вторую очередь).
Проект пока на начальной стадии развития, но уже определены базовые цели:
Модульность и развитие в соответствии с философией поставки гранулированной библиотеки, а не монолитного набора;
Поддержка статического связывания в режимах с BIE (Position-independent executables) и без PIE. Предоставление CRT (C runtime) и загрузчика PIE для статически связываемых исполняемых файлов;
Поддержка большей части функций стандартной Си-библиотеки с дополнениями POSIX и некоторыми специфичными для систем расширениями, востребованными в существующих приложениях;
Осторожное отношение к специфичным для производителей расширениям и их добавление только при необходимости. В отношении поддержки сторонних расширений предлагается применять подход проектов Clang и libc++;
Использование образцовых практик в разработке с использованием инструментария LLVM, таких как применение sanitizer и fuzzing-тестирования с самого начала.
Один из активных разработчиков LLVM rụtụrụ aka, что поставка libc в составе инструментария LLVM не лишена смысла, но обычно при подобной необходимости используют библиотеку musl, которая качественно написана, поддерживает различные архитектуры и предоставляет необходимую функциональность, в том числе поддерживает динамическое связывание. Оправданным может быть встраивание musl в LLVM и развитие его как синхронизированного с основным проектом форка.
Своё мнение также kwuputara автор проекта 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, а все остальные — второго.