Компилятор Clang включён в базовую поставку OpenBSD

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

Ждем-с, когда Тео перестанет ненавидеть слова MIT License.

So I guess the main advantage is the license?

No.

Or is clang technically (binaries, debug) better?

No.
Basically, this cannot be oversimplified by 1 line questions followed by 1 line answers.

https://marc.info/?l=openbsd-misc&m=149265369827301&w=2

и может быть на платформах i386 и amd64 в качестве альтернативы GCC.

Не может — lld недоработан. Вынуждены использовать GNU ld/rtld для открытого софта.

В чем прикол замены ГЦЦ на Шланг с ЛЛВМ?

В ФГМ.

Нужен для новых архитектур (arm64) и портов.
gcc-local никто заменять не собрался.

Не может — lld недоработан.

ППКС. У меня в генточке половина пакетов не собирается с lld 4.0, хотя clang+gold нормально прокатывает.

Какая странная аббревиатура для GPL v3

Нужен для новых архитектур (arm64) и портов.

а что, gcc не поддерживает какую-то архитектуру которую поддерживает clang? в чём конкретно преимущество использования clang вместо gcc?

В OpenBSD устаревшая версия gcc.

в общем насколько я понял, openbsd использует gcc десятилетней давности и от этого страдает. старый gcc используется в связи с какими-то проблемами с лицензированием компилятора под gpl v3 и им нужен компилятор под другой лицензией. особого выбора у них нет, т.к. clang - наверное единственная свободная альтенатива gcc. таким образом gcc и clang наверное даже не стоит сравнивать, потому что clang остаётся единственным доступным для них вариантом. или надо сравнивать clang и десятилетний gcc.

но, к слову, собирать что-то на генточке шлангом - это фууу. clang компилирует быстрее, но код у него получается или такой же как у гцц, или хуже. никогда не видел чтобы шланг собрал что-то чтобы работало быстрее чем после компиляции гцц. gcc + ccache во все поля например.

но для кросс-копиляции шланг - это конечно бэст оф зэ бест. особенно некоторые классы приложений, где производительность на cpu не важна, а важна производительность на gpu которая от компилятора с++ не зависит. хорошая штука в целом, только не до конца допиленая.

Ну ты забыл добавить ещё о том что для него сравнительно легко видятся бэкенды-трансляторы любого языка в llvm же байткод.

Хоть раста, хоть питона, хоть go. Это сильно может упростить линковку и ffi

И что, они не биздят?

А за эти годы не объявлялось, часом, желающих форкнуть gcc десятилетней давности и продолжать его развивать под старой лицензией? Идея, вроде, лежит на поверхности.

// Это, разумеется, для тех, кому старая лицензия важна. Лично меня gcc и под GPLv3 вполне устраивает.

он и так там запатчен по самое не балуйся

А за эти годы не объявлялось, часом, желающих форкнуть gcc десятилетней давности и продолжать его развивать под старой лицензией? Идея, вроде, лежит на поверхности.

Разработка компилятора уровня gcc или llvm+clang — сложная инженерная задача сама по себе, но вдобавок это ещё и сложная научная задача. Текущее положение дел в OpenBSD — патчи в собственную копию gcc 4.2.1 от полутора фанатиков — примерно тот максимум, на который можно рассчитывать.

эти разговоры про компиляцию других языков ходят с момента появления llvm, но что-то до сих пор не расцвёл ни питон, ни го новыми компиляторами. наверное потому что языкам с автоматическим сборщиком мусора нужен свой собственный рантайм, а код, даже откопмилированный в нативный, без этого рантайма работать не будет. это же не с++ который делает то, что запрограммировал программист, и что можно просто взять и откомпилировать, тут своя особенная уличная магия.

clang крут тем, что можно на линуксе собрать бинарник под мак и отдать его юзерам, этот бинарник на маке взлетит и будет работать без проблем. это очень мощная фича, без всякой иронии. гцц для такого понадобилось бы пересобрать с той же host-платформой, но другой target-платформой, пересобрать новым компилятором ещё кучу дерьмеца, а потом охранять весь получившийся билдрут как самое большое сокровище потому на его настойку в целом ушёл примерно человеко-год.

Уже можно ставить на домашний комп?

только этого и ждали. какой же домашний комп без clang? ни одна домохозяйка такое в руки не возьмёт.

LLVM прибит гвоздями к линуксовой Mesa3D/DRI. Если копнуть поширше, то внезапно окажется, что он есть в каждом современном десктопном линуксе, только не так заметно.

я всё жду, что в openbsd softpipe llvm-овский появится. у вас есть?

У «нас» это где?

а зачем ты ответ исправил? :)

зАТО правдивая.

Ну, не настолько уж и прибит. Я без проблем у себя собираю Mesa3D, не имея в системе LLVM.

Но в целом ты, конечно, прав.

а что там Open Watcom сдох?

Что там с PCC (Portable C Compiler)? Так и здох в недрах «бельевой» ОС? (AerieBSD)

Хотелось бы узнать как.

а потом охранять весь получившийся билдрут как самое большое сокровище потому на его настойку в целом ушёл примерно человеко-год.

Да. К тому же, гцц делается под кучку вонючего ГНУсного говнеца, отсюда проблемы со сборкой под другие платформы.

а что там Open Watcom сдох?

таки не совсем сдох, а очень даже есть прогресс на гитхабе, в этом вот форке: прогресс

там допилили 64-битность до ума, наконец-таки. ещё автосборка с travis CI работает, то есть поставить потыкать можно просто скачав свежий билд.

это вот прогресс. какая-то это вот прогресс.]жизнь идёт, потихоньку пилится.

из нерешённых проблем: это всё ещё C++00/C++98 и в этом вот качестве неплох (если мириться с костылями в iostream и STL/STLport). ну и оптимизатор на сегодняшний момент не самый актуальный.

компилятор тоже неплох для кросскомпиляции: фактически, он как и clang реализован как библиотека. вплоть до того, что стандатное ide с vi-подобным редактором юзает его как dll-ку.

а так-то, если писать простой С/С++ код в духе С++ начала нулевых, когда компилятор добавляет совсем немного отсебятины — вполне себе годная штучка.

новомодный С++1x там не работает, конечно же.

ещё в inferno вроде бы в kencc встроенном 64-битность потихоньку допилили, вроде бы.

отличия форка от этого вот

open-watcom beta

Last Update: 15 hours ago

ещё Watcom известен тем, что они переизобрели велосипед страдали NIH-синдромом: watcom не использовал ничего чего не собирал сам, то есть на каждой ОС все средства сборки полностью самодостаточны, и всю позикс-подобность они принесли с собой.

поэтому теоретически он должен быть полностью самодостаточен — достаточно портировать его CLIB, и всё готово под новой ОС в новом порте.

wiki:

Work in progress includes numerous Unix ports (Linux, FreeBSD, Solaris, OS X), support for new processors (AMD64, ARMv7), support for new language features and standards, a C++ STL implementation and more.

где конкретно этот порт под BSD — хз, надо спрашивать людей с гитхаба. в том форке, ЕМНИП, только Win/Lin/MacOSX 32/64-bit.

А каким набором GCC из современных версий OpenBSD может собраться и работать на x86-64? Версии GCC 6.3 и 7.1 справятся со сборкой? Кто-нибудь пробовал?