Почему FreeBSD отказывается от GCC в пользу Clang / LLVM?

Поэтому я занимался серфингом в сети и наткнулся на эту статью . В основном говорится, что FreeBSD , начиная с версии 10 и выше, будет отказываться от GCC в пользу Clang / LLVM .

Из того, что я видел в сети, Clang / LLVM - довольно амбициозный проект, но с точки зрения надежности он не может соответствовать GCC .

Существуют ли какие-либо технические причины, по которым FreeBSD выбирает LLVM в качестве инфраструктуры компилятора, или все сводится к вечным лицензиям GNU / GPL и BSD?

Этот вопрос имеет (как-то) соответствующую информацию об использовании GCC во FreeBSD

Описание: Основной причиной перехода с GCC на Clang является несовместимость лицензии GCC GPL v3 с целями проекта FreeBSD . Есть также политические проблемы, связанные с корпоративными инвестициями, а также требования к пользовательской базе. Наконец, ожидаемые технические преимущества связаны с соответствием стандартам и простотой отладки. Реальные улучшения производительности при компиляции и выполнении зависят от кода и являются предметом дискуссий; случаи могут быть сделаны для обоих компиляторов.

FreeBSD и GPL: у FreeBSD непростые отношения с GPL. Сторонники BSD-лицензии считают, что по-настоящему свободное программное обеспечение не имеет ограничений по использованию . Сторонники GPL считают, что ограничения необходимы для защиты свободы программного обеспечения, и, в частности, что возможность создавать несвободное программное обеспечение из свободного программного обеспечения является несправедливой формой власти, а не свободой. Проект FreeBSD, где это возможно, пытается избежать использования GPL :

Однако из-за дополнительных сложностей, которые могут возникнуть при коммерческом использовании программного обеспечения GPL, мы, тем не менее, стремимся заменять такое программное обеспечение представлениями по более свободной лицензии FreeBSD, когда это возможно.

FreeBSD и GPL v3: GPL v3 явно запрещает так называемый тивоизация кода, лазейку в v2 GPL , что позволило аппаратные ограничения , чтобы запретить в противном случае правовые изменения программного обеспечения пользователей. Закрытие этой лазейки было неприемлемым шагом для многих в сообществе FreeBSD:

В частности, поставщики устройств могут потерять больше всего, если большая часть программного обеспечения, лицензируемая в настоящее время в соответствии с GPLv2, сегодня перейдет на новую лицензию. У них больше не будет свободы использовать программное обеспечение GPLv3 и ограничивать модификацию программного обеспечения, установленного на их оборудовании ... Короче говоря, существует большая база потребителей OpenSource, которые внезапно очень заинтересованы в понимании альтернатив лицензионному программному обеспечению GPL.

Из-за перехода GCC на GPL v3 FreeBSD была вынуждена продолжать использовать GCC 4.2.1 (GPL v2), выпущенную еще в 2007 году , и в настоящее время значительно устарела. Тот факт, что FreeBSD не перешел на использование более современных версий GCC, даже с дополнительными трудностями, связанными с обслуживанием старого компилятора и исправлениями бэкпортинга, дает некоторое представление о силе требования избегать GPL v3. Компилятор C является основным компонентом базы FreeBSD, и « одна из (предварительных) целей для FreeBSD 10 - базовая система без GPL ».

Корпоративные инвестиции. Как и многие крупные проекты с открытым исходным кодом, FreeBSD получает финансирование и разработку от корпораций. Хотя степень, в которой FreeBSD финансируется или разрабатывается Apple, не так легко обнаружить, существует значительное совпадение, потому что Apple Darwin OS использует существенный код ядра BSD . Кроме того, сам Clang изначально был собственным проектом Apple, до того как был открыт в 2007 году . Поскольку корпоративные ресурсы являются ключевым фактором реализации проекта FreeBSD, удовлетворение потребностей спонсоров, вероятно, является существенным движущим фактором в реальной жизни .

База пользователей: FreeBSD является привлекательным вариантом с открытым исходным кодом для многих компаний, потому что лицензирование является простым, неограниченным и вряд ли приведет к судебным процессам. С появлением GPL v3 и новыми положениями , направленными против Tivoisation , было высказано предположение о том, что существует тенденция ускорения, ориентированная на поставщиков, в направлении более разрешительных лицензий . Так как очевидное преимущество FreeBSD для коммерческих организаций заключается в его разрешительной лицензии, все больше пользователей вынуждены уходить от GCC и GPL в целом.

Проблемы с GCC: Помимо лицензии, использование GCC имеет некоторые предполагаемые проблемы . GCC не полностью соответствует стандартам, и имеет множество расширений , которых нет в стандарте ISO C . Более 3 миллионов строк кода - это также « один из самых сложных и бесплатных программных проектов с открытым исходным кодом ». Эта сложность делает модификацию кода на уровне дистрибутива сложной задачей.

Технические преимущества: Clang имеет некоторые технические преимущества по сравнению с GCC . Наиболее заметными являются гораздо более информативные сообщения об ошибках и явно разработанный API для IDE, инструментов рефакторинга и анализа исходного кода. Хотя на веб-сайте Clang представлены графики, показывающие гораздо более эффективную компиляцию и использование памяти, результаты в реальном мире весьма разнообразны и в целом соответствуют производительности GCC. В общем случае исполняемые Clang двоичные файлы работают медленнее, чем эквивалентные двоичные файлы GCC:

Хотя использование LLVM быстрее при создании кода, чем GCC ... в большинстве случаев встроенные двоичные файлы GCC 4.5 работали лучше, чем LLVM-GCC или Clang ... в остальных тестах производительность была либо близка к производительности GCC, либо хорошо позади. В некоторых тестах производительность генерируемых Clang двоичных файлов была просто ужасной.

Вывод: Маловероятно, что эффективность компиляции станет существенным стимулом для принятия существенного риска на перенос большого проекта, такого как FreeBSD, на совершенно новый набор инструментов компилятора, особенно когда не хватает бинарной производительности. Однако ситуация не была действительно устойчивой. Учитывая выбор между: 1) использованием устаревшей GCC, 2) переходом на современный GCC и вынуждением использовать лицензию, несовместимую с целями проекта, или 3) переходом на стабильный компилятор с лицензией BSD, решение было, вероятно, неизбежно. Имейте в виду, что это относится только к базовой системе и поддержке со стороны дистрибутива; ничто не мешает пользователю установить и использовать современный GCC на своей коробке FreeBSD.

Стоит учесть, что FreeBSD в настоящее время использует GCC 4.2.1, как отмечено в ответе ire_and_curses, поэтому сравнение производительности не составляет 4.5 или даже 4.6 и не имеет никакого отношения к проекту. Поэтому вопросы, которые вы должны задавать:

1. Каковы прирост производительности нового Clang по сравнению со старым GCC, который использует проект?

2. Как сравнить те же самые двоичные файлы, скомпилированные в GCC 4.2.1, с новым Clang?

Из-за перехода GCC на GPL v3 FreeBSD была вынуждена продолжать использовать GCC 4.2.1 (GPL v2), выпущенную еще в 2007 году, и в настоящее время значительно устарела.

Если Clang отстает от нынешнего GCC, но все еще на несколько лет опережает внедренный GCC в проекте, тогда их решение развиваться будет вполне оправданным и действительно вдохновленным.

Несмотря на то, что GCC является GPLv3, полученные двоичные файлы, созданные GCC, никогда не имели каких-либо лицензионных ограничений. Ясно, что вы можете использовать GCC для создания программного обеспечения, которое подпадает под лицензию, которую вы хотите. Даже библиотека C, которая поставляется с GCC и включена в двоичный файл, не требует лицензий. http://www.gnu.org/licenses/gcc-exception-faq.html

Раздел 2 GNU GPLv3:

У вас есть разрешение на распространение произведения целевого кода, созданного путем объединения библиотеки времени выполнения с независимыми модулями, даже если такое распространение в противном случае нарушило бы условия GPLv3, при условии, что весь целевой код был сгенерирован с помощью допустимых процессов компиляции. Затем вы можете передать такую ​​комбинацию на условиях по вашему выбору , в соответствии с лицензированием независимых модулей.

«Приемлемый» означает, что компиляция не включает как GCC, так и GPL-несовместимое программное обеспечение. Это не ограничение: лицензионное программное обеспечение BSD может использоваться в процессе сборки с использованием GNU GCC.

Как вы можете видеть, вопреки сказанному выше, нет РЕАЛЬНОЙ причины, связанной с лицензией, отойти от GCC, поскольку нет несовместимости с использованием GCC во FreeBSD.

Настоящая причина этого изменения - политическая и оппортунистическая:

• BSD имеет свое собственное лицензирование, которое философски конкурирует с публичной лицензией GNU (как объяснено выше * ire_and_curses *),
• CLANG - это новый не-GPL-компилятор, инициированный спонсором FreeBSD, который, по-видимому, технически эквивалентен GCC, лицензированному под GPL (как описано выше в * ire_and_curses *).

Эти факты создают возможность для FreeBSD отойти от GCC и избавиться от него: они на самом деле не обязаны, поскольку они все еще могут использовать GCC для создания свободного или лицензированного BSD программного обеспечения, но они хотят придерживаться философия "все лицензионное программное обеспечение BSD".

Я не эксперт, но я понимаю, что Clang / LLVM использует меньше ресурсов, чем GCC, и работает быстрее.

http://clang.llvm.org/features.html#performance

Если вы работаете в среде, где вам нужно много раз создавать, такая производительность может превратиться в реальную экономию затрат и времени на электроэнергию. Если это реально.