Почему FreeBSD удерживает от использования GCC в пользу Clang/LLVM?
Что точно Вы видите? Со сценарием
opts="-x ''"
echo curl http://somepage $opts
opts="-x \'\'"
echo curl http://somepage $opts
С ударом 3.2.39 или 4.1.5, я вижу
+ opts='-x '\'''\'''
+ echo curl http://somepage -x ''\'''\'''
curl http://somepage -x ''
+ opts='-x \'\''\'\'''
+ echo curl http://somepage -x '\'\''\'\'''
Первый вызов к curl (хорошо, echo curl) имеет последний аргумент, состоящий из двух символов ''. Трассировка выходит из специальных символов: ' появляется как '\'' (общая идиома, чтобы “выйти” из одинарных кавычек в одинарных кавычках). Официально, ''\'''\''' состоит из пустой единственно заключенной в кавычки строки '' сопровождаемый заключенным в кавычки из обратной косой черты символом \', с другой стороны '', снова \', и финал ''. (Ksh показывает это как немного более читаемое $'\'\''.) Второй вызов передает четыре символа \'\'.
Под нормальным sh анализирующие правила Вы не можете привести пустой аргумент путем расширения неупомянутой переменной. Word, разделяющий сокращения только там, где существует непробел или заключенный в кавычки символ.
Так как Вы используете удар, можно поместить несколько опций в массив. Это также работает в ksh и zsh.
opts=(-x "")
curl http://somepage "${opts[@]}"
Для этого конкретного случая можно переопределить переменную среды вместо этого.
http_proxy= curl http://somepage
Сводка: основная причина переключения с GCC для Лязга является несовместимостью лицензии GPL v3 GCC с целями проекта FreeBSD. Существуют также политические вопросы, чтобы сделать с корпоративными инвестициями, а также требованиями базы пользователей. Наконец, там ожидаются технические преимущества, чтобы сделать с соответствием стандартов и простотой отладки. Повышения производительности реального мира в компиляции и выполнении являются определенными для кода и спорными; случаи могут быть сделаны для обоих компиляторов.
FreeBSD и GPL: FreeBSD имеет неудобные отношения с GPL. Защитники BSD-лицензии полагают, что действительно бесплатное программное обеспечение не имеет никаких ограничений использования. Защитники GPL полагают, что ограничения необходимы для защиты свободы программного обеспечения, и конкретно что способность создать небесплатное программное обеспечение из бесплатного программного обеспечения является несправедливой формой питания, а не свободы. Проект FreeBSD, если это возможно, старается избегать использования GPL:
Из-за дополнительных сложностей, которые могут развиться в коммерческом использовании программного обеспечения GPL, мы действительно, однако, пытаемся заменять такое программное обеспечение представлениями в соответствии с более расслабленной лицензией FreeBSD, когда это возможно.
FreeBSD и GPL v3: GPL v3 явно запрещает так называемый Tivoisation кода, лазейки в GPL v2, который позволил аппаратным ограничениям запретить в других отношениях легальные модификации программного обеспечения пользователями. Закрытие этой лазейки было недопустимым шагом для многих в сообществе 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, не является легко поддающейся обнаружению, существует значительное перекрытие, потому что Darwin Apple ОС использует существенный BSD-порожденный код ядра. Кроме того, сам Лязг был первоначально внутренним проектом Apple, прежде чем быть открыто полученным в 2007. Так как корпоративные ресурсы являются ключевым фактором проекта FreeBSD, удовлетворение потребностей спонсора является, вероятно, значительным реальным драйвером.
База пользователей: FreeBSD является привлекательной опцией с открытым исходным кодом для многих компаний, потому что лицензирование просто, нестрого и маловероятно привести к судебным процессам. С прибытием GPL v3 и новых anti-Tivoisation условий, было предложено, чтобы было ускорение, управляемая поставщиками тенденция к большему количеству разрешающих лицензий. Так как воспринятое преимущество FreeBSD для коммерческих объектов заключается в своей разрешающей лицензии, там увеличивает давление базы корпоративных пользователей для отодвигания от GCC и GPL в целом.
Проблемы с GCC: Кроме лицензии, с помощью GCC имеет некоторые воспринятые проблемы. GCC не является совместимыми полностью-стандартами, и имеет много расширений, не найденных в стандарте ISO C. В более чем 3 миллионах строк кода это - также "один из самых сложных и бесплатных проектов / проектов программного обеспечения с открытым исходным кодом". Эта сложность делает модификацию кода уровня дистрибутива сложной задачей.
Технические преимущества: Лязг действительно имеет некоторые технические преимущества по сравнению с GCC. Самый известный намного более информативные сообщения об ошибках и явно разработанный API для IDE, рефакторинга и аналитических инструментов исходного кода. Хотя графики подарков веб-сайта Лязга, указывающие на намного более эффективную компиляцию и использование памяти, результаты реального мира являются довольно переменными, и широко в соответствии с производительностью GCC. В целом, Произведенные из лязга двоичные файлы, выполняемые более медленно, чем эквивалентные двоичные файлы GCC:
В то время как использование LLVM быстрее в строительных нормах и правилах, чем GCC... в большинстве экземпляров, которые созданные двоичные файлы GCC 4.5 выполнили лучше, чем LLVM-GCC или Лязг... в остальной части тестов, которыми производительность была или близко к тому из GCC или далеко позади. В некоторых тестах производительность сгенерированных двоичных файлов Лязга была просто ужасна.
Заключение: очень маловероятно, что эффективность компиляции была бы значительным фактором мотивации для взятия на себя существенного риска перемещения крупного проекта как FreeBSD к совершенно новому набору инструментальных средств компилятора, особенно когда двоичной производительности недостает. Однако ситуация не была действительно надежна. Учитывая выбор между 1) выполнением устаревшего GCC, 2) Перемещением в современный GCC и быть вынужденным использовать лицензию, несовместимую с целями проекта или 3) перемещением в стабильный BSD-лицензированный компилятор решение было, вероятно, неизбежно. Примите во внимание, что это только относится к основной системе и поддержке со стороны распределения; ничто не препятствует тому, чтобы пользователь установил и использовал современный GCC на их поле FreeBSD самостоятельно.
-
1Сравнительный тест, который Вы процитировали, от старой версии Лязга. Сравнительные тесты для последних версий, кажется, последние версии, ближе. Мое собственное исследование для простых программ поместило Лязг 3.0 на несколько процентов быстрее, чем GCC 4.6, но GCC был на 20% быстрее на потоковой версии. phoronix.com/scan.php?page=news_item&px=MTA5Nzc является более новым сравнительным тестом Phoronix. – Sean 07.11.2012, 23:14
-
2"GCC не является совместимыми полностью-стандартами": разве не возможно использовать переключатели компилятора для обеспечивания соблюдения к данному стандарту? – Giorgio 28.01.2013, 17:21
-
3В первую очередь, не читайте слишком много в сравнительные тесты Phoronix или скорее не читайте их вообще. Во-вторых, это верно, что GCC не является полностью стандартами, совместимыми по умолчанию, если Вы явно не указываете стандарт, если Вы не сделаете то этому включат расширения GNU также, но это походило бы на нечетную причину использовать Лязг, вместо этого, хотя, так как они также реализуют обычно используемые расширения GNU, потому что они борются за Лязг, являющийся применимым как понижение замены для GCC. – kyrias 18.06.2013, 22:21
-
4@Giorgio: Нет. См. gcc.gnu.org/c99status.html для примера - и это - просто C99 (который сам 14 лет теперь). Также gcc.gnu.org/onlinedocs/libstdc++/manual/status.html - лязг имеет лучшую поддержку и (я думаю, что это полно - и в противном случае это определенно, по крайней мере, лучше). – Tim Čas 15.08.2013, 20:19
-
5@Demizey я не защищаю Phoronix, но если Вы собираетесь отклонить что-то, которое необходимо, по крайней мере, обеспечить допустимую причину. – Mario 20.02.2014, 08:29
Я не эксперт, но мое понимание является Clang/LLVM, использует меньше ресурсов, чем GCC и более быстр.
http://clang.llvm.org/features.html#performance
При выполнении среды, где необходимо создать много материала, много времен, та производительность может превратиться в реальные сбережения в затратах на энергию и время. Если это реально.
-
1.. и существуют инструменты для сокращения повторяющегося времени компиляции далее - ccache.samba.org Не берет в голову очевидные возможности для параллельной компиляции (см. distcc), времена ссылки имеют тенденцию быть более трудными решить в крупных проектах – Rob11311 06.07.2014, 19:17
-
2
-
3
Одна вещь достойная рассмотрения состоит в том, что FreeBSD в настоящее время использует GCC 4.2.1, как отмечено в ire_and_curses, отвечают таким образом, что сравнения производительности не имеют 4,5, или даже 4.6 не действительно относятся к проекту. Поэтому вопросы, которые необходимо задавать:
Каково увеличение производительности нового Лязга по сравнению с более старым GCC, который использует проект?
Как делают те же двоичные файлы, скомпилированные в GCC 4.2.1, выдерживают сравнение с новым Лязгом?
Из-за перемещения GCC к GPL v3 FreeBSD был вынужден остаться использовать GCC 4.2.1 (GPL v2), который был выпущенным путем назад в 2007 и теперь значительно устарел.
Если Лязг отстает от текущего 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* объясненный выше),
- ЛЯЗГ является новым non-GPL компилятором, инициируемым спонсором FreeBSD, который, кажется, технически эквивалентен GPL-лицензированному GCC (как описано выше *ire_and_curses*).
Эти факты создают возможность для FreeBSD, чтобы переехать от GCC и избавиться от него: они на самом деле по закону не вынуждены, поскольку они могли все еще использовать GCC для создания бесплатного или BSD-лицензированного программного обеспечения, но они хотят придерживаться лицензируемого программного обеспечения "всего BSD" философия.
-
1Извините, я должен был провалить это. К сожалению, Ваше отсутствие близости с BSDs и шоу минимумов программного обеспечения. Только для справки это было политическим не техническое решение, которые приводят BSDs от переключения от его традиционного Портативного компилятора C (PCC) до GCC в начале девяностых. Лязг является проектом Apple! Как кто-то, кто использует GCC на ежедневной основе для проживания на OpenBSD, который пытается попятиться к PCC, Вы просто неправы во всех учетных записях. – Predrag Punosevac 21.05.2013, 07:20
-
2Это не о получающихся двоичных файлах, это о том, что gcc является частью FreeBSD - поэтому, ограничения лицензии действительно имеют значение. – sstn 24.08.2013, 16:26
-
3Если религия проекта говорит "№ GPLv3" затем, технические аспекты исчезают - просто предполагают, что они использовали, например, компилятор Microsoft. – Thorbjørn Ravn Andersen 11.09.2013, 22:44
-
4Это - единственный ответ, который указывает правильно на это
license of compiler != license of end product. Жалобы на лицензию компилятора не могут возможно быть релевантными, если пользователь не понимает лицензию. – Brandin 06.09.2014, 11:42 -
5Это не о том, подпадают ли произведенные двоичные файлы под GPLv3, это - требуют ли изменения в самом компиляторе соответствия GPLv3. Поставщики оборудования часто изменяют компилятор запаса, чтобы работать с их аппаратными средствами лучше или использовать в своих интересах аппаратные средства собственными способами. Удаление риска, что Ваши пользовательские изменения должны выполнить GPLv3 или рискнуть судебным иском, является грандиозным предприятием для таких организаций. Это действительно - лицензия компилятора, который имеет значение здесь. – David Harks 19.10.2014, 15:46