Чому FreeBSD знецінює GCC на користь Clang / LLVM?


241

Тому я серфінгував по мережі та натрапив на цю статтю . В основному йдеться про те, що FreeBSD , починаючи з версії 10 і вище, знецінить GCC на користь Clang / LLVM .

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

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

Це запитання має (якось) релевантну інформацію про використання GCC у FreeBSD

Відповіді:


361

Короткий зміст: Основна причина переходу з GCC на Clang - це несумісність ліцензії GPL v3 GPL з цілями проекту 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, не легко виявити, є суттєве перекриття, оскільки Darwin OS від Apple використовує значний код ядра BSD . Крім того, сам Клэнг був спочатку власним проектом Apple, перед тим як його відкрити в 2007 році . Оскільки корпоративні ресурси є ключовим фактором проекту FreeBSD, задоволення потреб спонсора, ймовірно, є важливим фактором у реальному світі .

База даних: FreeBSD - це привабливий варіант з відкритим кодом для багатьох компаній, оскільки ліцензування є простим, необмеженим та навряд чи призведе до судових позовів. З появою GPL v3 та нових положень про боротьбу з обмеженнями громадськості було припущено, що існує прискорена, орієнтована на виробників тенденція до отримання більш дозвільних ліцензій . Оскільки сприйняте перевага 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.


4
Тест, який ви цитували, базується на старій версії Clang. Орієнтирами для останніх версій, здається, є новітні версії. Мої власні дослідження для простих програм поставили Clang 3.0 на пару відсотків швидше, ніж GCC 4.6, але GCC був на 20% швидшим у потоковій версії. phoronix.com/scan.php?page=news_item&px=MTA5Nzc - це новіший орієнтир Phoronix.
Шон

6
"GCC не відповідає стандартам повністю": Чи не можна використовувати компілятори компілятора для забезпечення відповідності заданому стандарту?
Джорджіо

4
Перш за все, не читайте занадто багато у тестах Phoronix, а точніше, не читайте їх взагалі. По-друге, це правда, що GCC не відповідає стандартам за замовчуванням, якщо ви чітко не вкажете стандарт, якщо ви цього не зробите, увімкнено також розширення GNU, але це може здатися дивним приводом для використання Clang замість цього, оскільки вони також реалізують найбільш часто використовувані розширення GNU, оскільки прагнуть, щоб Clang був корисним як крапля в заміні GCC.
kyrias

1
@Giorgio: Ні. Приклад див. На прикладі gcc.gnu.org/c99status.html - і це лише C99 (якому зараз вже 14 років). Також gcc.gnu.org/onlinedocs/libstdc++/manual/status.html - clang має кращу підтримку для обох (я думаю, що це повноцінно - а якщо ні, то, безумовно, принаймні краще).
Тім Час

4
@Demizey Я не захищаю Phoronix, але якщо ви збираєтесь відхилити щось, вам слід принаймні вказати поважну причину.
Маріо

38

Варто врахувати, що 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 році і тепер значно застарів.

Якщо Кланг відстає від поточної GCC, але все ще є світлі роки попереду від впроваджених GCC у проекті, то їхнє рішення розвиватися добре обґрунтовано та справді надихає.


19

Незважаючи на те, що 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 Public (як пояснено вище * ire_and_curses *),
  • CLANG - це новий компілятор, який не є GPL, ініційований спонсором FreeBSD, який, як видається, технічно еквівалентний GCC, що має ліцензію GPL (як описано вище * ire_and_curses *).

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


5
Вибачте, що довелося проголосувати за це. На жаль, виявляється ваша незнайомість з BSD та мінімальними програмами. Тільки для запису, що політичне, а не технічне рішення призвело до того, що BSD перейшли від традиційного портативного компілятора C (PCC) до GCC на початку дев'яностих. Кланг - проект Apple! Оскільки хтось, хто щодня використовує GCC, щоб жити на OpenBSD, який намагається повернутися до PCC, ви просто помиляєтесь у всіх облікових записах.
Predrag Punosevac

5
Йдеться не про отримані бінарні файли, а про те, що gcc є частиною FreeBSD - тому ліцензійні обмеження мають значення.
sstn

3
Якщо релігія проекту говорить "Ні GPLv3", то технічні аспекти згасають - просто уявіть, що вони використовували, наприклад, компілятор Microsoft.
Thorbjørn Ravn Andersen

3
Це єдина відповідь, яка правильно вказує на це license of compiler != license of end product. Скарги на ліцензію компілятора, можливо, не можуть бути актуальними, якщо користувач не розуміє ліцензію.
Брандін

6
Справа не в тому, чи підлягають виробленню бінарні файли під GPLv3, а чи потрібно зміни компілятора вимагати відповідності GPLv3. Постачальники обладнання часто модифікують компілятор запасів, щоб краще працювати зі своїм обладнанням або ж скористатися обладнанням у власний спосіб. Усунення ризику, що ваші користувацькі зміни повинні відповідати GPLv3 або ризикувати юридичні дії, є великою справою для таких організацій. Тут дійсно важлива ліцензія компілятора.
Девід Харкс

7

Я не експерт, але я розумію, що Clang / LLVM використовує менше ресурсів, ніж GCC, і це швидше.

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

Якщо ви працюєте в середовищі, в якому потрібно багато разів збирати багато матеріалів, продуктивність може перетворитись на реальну економію витрат енергії та часу. Якщо це реально.


Незначні .. і є інструменти для подальшого зменшення повторюваної компіляції - ccache.samba.org Незважаючи на очевидні можливості паралельної компіляції (див. Distcc), час великих посилань важче вирішити у великих проектах
Rob11311

Так, дуже добре, але отриманий двійковий код повільніше; p
іржа

1
@rustyx не порівняно з gcc 4.2!
Майлз Рут
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.