LINUX.ORG.RU

Debian: clang способен заменить gcc

 , ,


0

1

Sylvestre Ledru провел эксперимент по сборке репозитория Debian с помощью компилятора clang. Вопреки ожиданиям, результаты оказались обнадеживающими:

На мой взгляд, clang уже стабилен и достаточно хорош для пересборки большинства пакетов Debian, хотя многие из них потребуют незначительных исправлений.

В ближайшие несколько лет, учитывая лучшие инструмены статического анализа кода, clang может заменить gcc/g++ как компилятор C/C++ по умолчанию в дистрибутивах Linux и BSD.

Разработчики clang продвигаются очень быстро: с версией 2.9 не собиралось 14.5% пакетов, а с 3.0 - 8.8%. Сделаны существенные шаги: chromium/chrome собираются по умолчанию с помощью clang, Xcode по умолчанию предоставляет clang, FreeBSD работает над переходом с gcc на clang и т. д.

Однако для Debian важно, чтобы clang справлялся со всеми поддерживаемыми архитектурами (11 официальных, 6 неофициальных).

Собрать не удалось 1381 пакет из 15658. Самая частая причина неудачи - более строгое следование стандартам со стороны clang.

Найденные баги будут отправлены в багтрекер Debian вместе с патчами. Автор исследования продолжит тестировать новые версии clang.

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

★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от tailgunner

FreeBSD настолько уверенно чувствует себя на MIPS, что собирается перейти на LLVM там?

У FreeBSD лучше поддержка MIPS чем ARM, INHO. Тут Juniper код подгоняла не так давно. Логично было бы апи наличии clang в базовой системе им и для мипсов собирать (или доделать поддержку mips). Но в mips порт не влазил, поэтому могу ошибаться.

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

У FreeBSD лучше поддержка MIPS чем ARM, INHO. Тут Juniper код подгоняла не так давно.

Тогда понятно, спасибо.

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

PowerPC64? Это какая ОС?

Все так быстро забыли о Power Mac G5 и Xserve G5? Шести лет ещё не прошло, как последние покупали, пашут как миленькие.

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

PowerPC64? Это какая ОС?

Все так быстро забыли о Power Mac G5 и Xserve G5?

Все забыли (а кое-то и не знал), что покойники были 64-битовыми и на Clang.

tailgunner ★★★★★
()
Ответ на: комментарий от baka-kun

Все так быстро забыли о Power Mac G5 и Xserve G5? Шести лет ещё не прошло, как последние покупали, пашут как миленькие.

и с чего там «LLVM является основным компилятором»? там и Xcode четвертый c llvm уже не встанет - Apple официально забила на PPC

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

и с чего там «LLVM является основным компилятором»? там и Xcode четвертый c llvm уже не встанет

Я когда Xcode 3.2.5 перестал быть «с llvm»?

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

Я когда Xcode 3.2.5 перестал быть «с llvm»?

ага, посмотри его системные требования - внезапно обнаружишь Mac OS X 10.6, которые ни разу на PPC не встанет

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

ага, посмотри его системные требования - внезапно обнаружишь Mac OS X 10.6, которые ни разу на PPC не встанет

Ты это мне рассказываешь, КО?

Просто 3.2.5 — последняя версия, которая официально позволяет создавать UB. Или ты думаешь, что собирать PowerPC бинарник обязательно на том же процессоре? :)

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

Или ты думаешь, что собирать PowerPC бинарник обязательно на том же процессоре? :)

нет, но даже если кросскомпиляцию принять за основной метод разработки под платформу, которая недавно была самостоятельной, - llvm там не основной компилятор, а экспериментальный

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

От чего?

А от чего освобождает? :)

Или, «in multa sapi­entia mul­tus sit mae­ror»?

baka-kun ★★★★★
()
Ответ на: комментарий от buddhist

А причем тут objC? С++ маку тоже нужен, как ни странно. Меня интересует известная проблема п++ в части зависимостей исполняемого кода от версии компиллятора и имеющегося рантайма. А так же поведение скомпилированного кода при наличии зоопарка из рантаймов. Что будет местами неизбежно в линухе, особенно при использовании сторонних библиотек.

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

Не поверишь! NAG library, например :)

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

Вся cernlib вообще-то, тот же lapack, куча модулей для R.

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

А вот отсюда поподробнее, пожалуйста. Что у ifort не так с соблюдением стандартов?

Если только из 2003го стандарта не все реализовали...

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

а) много чего уже написано на f77

б) система заморожена. В момент заморозки был только g77.

gfortran появился относительно недавно.

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

Понятно.

Но новый-то код зачем на f77 писать? В f90 программах отлично работают процедуры, написанные на f77.

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

а) Система заморожена, значит заморожены и версии компилятора, так как нет сил проверять совместимость и отлавливать баги в новых версиях.

б) проблемы написания программ на f77 сильно преувеличены. Язык, как язык.

Основные сложности относятся к физике, а не программированию.

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

а) Система заморожена, значит заморожены и версии компилятора, так как нет сил проверять совместимость и отлавливать баги в новых версиях.

В коммерческих компиляторах всё отлично совместимо. За g77 и gfortran не уверен, опыта использования немного.

б) проблемы написания программ на f77 сильно преувеличены. Язык, как язык.

Понятно, что язык как язык. Просто в f90 и более поздних версиях много фич, сильно облегчающих жизнь. Ежели их вводят в стандарт, то как-то грех не использовать. Зря что-ли люди стараются?

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

В коммерческих компиляторах всё отлично совместимо. За g77 и gfortran не уверен, опыта использования немного.

покажи мне хоть одну сборку cernlib с помощью коммерческих компиляторов. Так же при использовании того же интеловского мы имеем проблемы при линковке с библиотеками собранными gcc

Иными словами: лучшее — враг хорошего. Занимать исследованием других сборок, если имеющееся решение есть и работает, не шибко осмысленно.

Понятно, что язык как язык. Просто в f90 и более поздних версиях много фич, сильно облегчающих жизнь. Ежели их вводят в стандарт, то как-то грех не использовать. Зря что-ли люди стараются?

Ну облегчат эти фичи жизнь на 0.5% после того как просадишь 10% времени на разборку с ними. Основные проблемы лежат не в области программирования.

Если что-то начинать с нуля сейчас, то это будет некий гибрид С/С++ и Python в силу имеющихся библиотек. Если подумать, то можно и R приткнуть. Сейчас же у меня f77/C/C++/perl.

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

покажи мне хоть одну сборку cernlib с помощью коммерческих компиляторов.

У меня нет. А что, такая проблема собрать?

Так же при использовании того же интеловского мы имеем проблемы при линковке с библиотеками собранными gcc

Собирать надо всё одним и тем же компилятором, естессвенно.

Ну облегчат эти фичи жизнь на 0.5% после того как просадишь 10% времени на разборку с ними.

Чего там разбираться-то? Берёшь и пишешь код. Только без дурацких отступов, без десятков аргументов в процедурах, common блоков и прочего геморроя.

Основные проблемы лежат не в области программирования.

Это да.

Сейчас же у меня f77/C/C++/perl.

Ужос! :)

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

Извиняюсь что долго отвечал.

Я похоже наврал, что это связанно непосредственно с GPLv3. Вот тут немного больше информации (в частности, в этом комменте). Если в кратце, то, как я понял, проблема в том, что если эппл хочет замёрджить свои изменения обратно в GCC, то им нужно передать права обратно FSF («copyright assignment policy»). А они этого не захотели делать.

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

А что, такая проблема собрать?

Да.

Собирать надо всё одним и тем же компилятором, естессвенно.

Ога, а затем проверять что все функции пашут, как ожидается.

Чего там разбираться-то? Берёшь и пишешь код. Только без дурацких отступов, без десятков аргументов в процедурах, common блоков и прочего геморроя.

а) emacs позволяет автоматом форматировать отступы.

б) Десятки аргументов в процедурах решаются разумным планированием

в) common блоки не проблема, особенно если выносишь их в отдельные заголовочные файлы

г) прочего гемороя не особо наблюдается

По мне так C++ гораздо сложнее в использовании и проблемнее. Минус f77 — это его многословность, но и тут если алгоритм понятен, то всё решаемо.

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

Си — не совсем язык высокого уровня. Поэтому там нужен goto на машинную инструкцию.

Машинные инструкции появятся после компиляции и неизвестно какие они будут, а метки исходника нормально обслуживаются обычным goto. Или тебе нужен оператор запускающий машинный код с нужного адреса? Мало ассемблерных вставок, сделаем вставки машинного кода!

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

Ну хотя бы возможность засунуть адрес метки в переменную должна быть. В общем, курите исходники gforth.

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

Ога, а затем проверять что все функции пашут, как ожидается.

Что там может быть не так как ожидается? Если работа функции зависит от версии компилятора, то это какая-то неправильная функция получается.

Минус f77 — это его многословность

Вот как раз все эти апдейты в f90 и после этот минус и устраняют.

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

Передача прав - это благо, особенно передача коллективному органу типа FSF.

Когда в исходниках 100500 копирайтов, проще написать свою программу. Или застрелиться.

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

Если работа функции зависит от версии компилятора, то это какая-то неправильная функция получается.

Может быть и так, но основная цель отнюдь не ловля блох в сторонних библиотеках.

В документации cernlib описаны не только фичи, но и баги.

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

Ну хотя бы возможность засунуть адрес метки в переменную должна быть.

Тогда это не метка а аналог спектрумбейсикового RANDOMIZE USR адрес

В общем, курите исходники gforth.

Только сиобразной непотребщины мне и нехватало.

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

В документации cernlib описаны не только фичи, но и баги.

Кстати, документация говорит, что на некоторых платформах оно таки собирается коммерческими компиляторами. Очень странно, что на линукс/интел только gcc.

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

Сейчас же у меня f77/C/C++/perl.

I know that feel, bro.

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

А арматуру обмотанную изолентой можно назвать оружием ближнего боя из композитных материалов?

нет конечно, арматура - железная, это не композит

shty ★★★★★
()
Ответ на: комментарий от A-234

Мне кажется, что ваш пример относится скорее к значениям по умолчанию а не к константным объектам.

рекомендую посмотреть ещё раз на код и на обсуждение

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

нет конечно, арматура - железная, это не композит

А если деревянную ручку насадить и изолентой примотать? Тогда целых три компонента будет: сталь, дерево, изолента. ;)

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

А если деревянную ручку насадить и изолентой примотать?

думаешь с композитной дилдой удастся обойти папу карло на конкурсе буратин?

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

уважаемый der fliegender Holländer, Вы глубоко заблуждаетесь насичот темы топика и про связку clang/llvm в частности

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

Не, я с gcc слезать не собираюсь, просто LLVMом интересуюсь.

вот это меня больше всего веселит, почему то половина людей в топике (да, ТС заголовком новости знатно набросил, хотя и толстовато) решила, что раз вышел clang, который умеет собирать большинство пакетов debian, то с какого-то надо всенепременно «слезать»

а я скажу - больше «конпеляторов», хороших и разных

Скажи пару слов, если не затруднит.

ну так ты спрашивай, а уж меня не затруднит

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

а я скажу - больше «конпеляторов», хороших и разных

Так ведь правильно же. Согласен. Потому и интересуюсь альтернативами gcc.

то с какого-то надо всенепременно «слезать»

Ну это я неправильно выразился, поторопился. Действительно, скорее речь идёт о перспективах альтернативных компилеров.

ну так ты спрашивай, а уж меня не затруднит

Так, собственно, в том и вопрос: clang/llvm - реальная альтернатива gcc, стоит ли уделить ему серьёзное внимание?

И ещё вопрос: а какие ещё работоспособные альтернативные компиляторы имеются? Интересуют только для Линукса.

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

И в результате будет вызван конструктор и отработает он естественно в рантайм, за исключением простых типов.

A-234 ★★★★★
()
Ответ на: комментарий от yvv

Зачем так мучиться? gfortran же вроде f90 компилирует нормально?

f95

alex-w ★★★★★
()
Ответ на: комментарий от DeVliegendeHollander

Так, собственно, в том и вопрос: clang/llvm - реальная альтернатива gcc, стоит ли уделить ему серьёзное внимание?

ну, я больше заходил со стороны llvm - проект очень серьёзный, написанный правильно

clang, судя хотя бы по новости, проект не менее серьёзный :)

и, самое главное, глядя на clang, gcc начинает нехило так подтягиваться, в частности там сейчас довольно сильно ровняют архитектуру, что не может не радовать

кстати, хороший критерий устойчивости кода - если код собирается несколькими компиляторами, количество неточностей скольких мест снижается на порядок, поэтому я всегда стараюсь подтягивать, например, msvc и gcc (иногда icc), теперь ещё +1 появляется - сплошной руль

И ещё вопрос: а какие ещё работоспособные альтернативные компиляторы имеются? Интересуют только для Линукса.

как минимум - open64, icc, open watcom

есть ещё платные, типа Comeau C++, PathScale C++, Portland Group C++, IBM XL C/C++, ну и ещё пара-тройка

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

Передача прав - это благо, особенно передача коллективному органу типа FSF.

То то, тут поливают грязью OpenOffice который поступал так же. а FSF ничем не лучше других - пример с библиотеками DWG показывает - мы хотим что бы было GPL v3, так другим не удобно, пофик. прогнуться - зато мы хотим. И чем это хорошо ?

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

Хорошо. Внушает оптимизм. Спасибо за развёрнутый ответ.

PS: Несколько удивило (и порадовало), что Open Watcom жив. Я про него уже лет 10 не слышал, хотя...я не слишком и интересовался. :)

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