LINUX.ORG.RU

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

 ,


0

3

Компилятор Clang добавлен в базовую сборку OpenBSD для платформ i386 и x86_64 в качестве альтернативы GCC.

Ранее Clang поставлялся лишь для arm64.

>>> Подробности



Проверено: Shaman007 ()
Последнее исправление: sudopacman (всего исправлений: 3)

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

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

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

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

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

devl547 ★★★★★
()
Ответ на: комментарий от Arlecchino

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

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

anonymous
()
Ответ на: комментарий от Arlecchino

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

energetix_user ★★
()
Последнее исправление: energetix_user (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

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

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

anonymous
()
Ответ на: комментарий от energetix_user

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

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

anonymous
()
Ответ на: комментарий от buratino

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

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от splinter

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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.

anonymous
()

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

iZEN ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.