Кастомный GCC для определенного пакета

init_6 ты не делал что-то подобное?

init_6 ты не делал что-то подобное?

Это был не init_6, а megabaks, и называлось оно gcc-switcher (впрочем, через несколько правок будет работать и сейчас).

Нет. Называлось оно /etc/portage/package.env и оно существовало задолго до поделий megabaks-а.

/etc/portage/package.env

Ну, package.env не отменяет нужность ещё одного скрипта или функции в portage/bashrc, который будет выполнять переключение всего environment, а не только изменение значения переменных.

Ну, package.env не отменяет нужность ещё одного скрипта

Отменяет. Читай маны неуч.

Ты сам-то читал? package.env реализует только переназначение переменных окружения. Talk is cheap, show me the code!

package.env реализует только переназначение переменных окружения

Неужели? Риальне? Так говоришь у тебя СС и CXX это не переменные окружения? В общем слив защитан.

ЗЫ: Вот сейчас сижу и =dev-libs/efl-1.19.0 собираю clang-ом именно при помощи package.env и не потому-что так желает моя левая пятка а потому-что gcc 5.4.0 его не берёт.

Делаешь по аналогии с https://wiki.gentoo.org/wiki/Clang через /etc/portage/package.env (как уже посоветовал init_6). Перекрываешь для пакета переменные окружения CC/CXX/AR/NM/RANLIB нужными, с указанием бинарников непосредственно из «/usr/x86_64-pc-linux-gnu/gcc-bin/х.х.х/» (в данном случае x86_64-pc-linux-gnu - CHOST, х.х.х — нужная версия GCC).

На FreeBSD это делается настройкой условной компиляции в /etc/make.conf. Но смысла в этом никакого: плохо написанный код остаётся плохим и в откомпилированном виде, поскольку в нём используются побочные эффекты конкретной версии компилятора, проявляющие себя совсем не так, как задумал автор, в другой версии рантайм-окружения.

Почему не переводите сборку на GCC 6.3?

Почему не переводите сборку на GCC 6.3?

Это ты не меня а хотя-бы Pinkbyte спрашивай. Он всяко ближе к внутренней кухне принятия решений. Однако вангую что он тебя пошлет в сторону bug #582084 и которого в принципе становится ясен ответ на твой вопрос.

Когда я смотрю на подобные баги, складывается впечатление, что разрабы GCC свои релизы вообще не тестят...

В общем слив защитан.

Пусть будет так. Мне лень спорить с фанатиком.

Как бы там ни было… Но вот вышеозвученный dev-libs/efl-1.19.0 вываливается одинаково и gcc-5.4.0 и clang не осилил.

generic/evas/pdf/generic_evas_pdf_evas_image_loader_pdf-main.o: In function `poppler_init(char const*, int, int, int)':
generic/evas/pdf/main.cpp:(.text+0x106): undefined reference to `poppler::document::load_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation)

Дело известное и проще всего поставить параллельно старый gcc-4.

Лёл, это разве не надо зарепортить?..

Это не в компилере дело, а в бажном коде. И попытайся собрать чем-то нормальным, типа 6.3 или даже 7.1, они всегда ориентировались на новые компиляторы...

Лёл, это разве не надо зарепортить?..

Кому надо? Тебе надо? Вперед.

И попытайся собрать чем-то нормальным, типа 6.3 или даже 7.1, они всегда ориентировались на новые компиляторы...

Ты 4.9 попутал с 6.3/7.1 а так всё нормально.

Мнэ... а каким образом кривой код, который таки перестал собираться - проблема компилятора? Чего-то C99 работает на всех компилерах, без каких-либо проблем. А на различные особенности и свойства компилятора ведь и так просили не полагаться...

Моя задница таки чует, что на 6.3 может и заработать...

а если стдлиб взять libc++ ?

Мнэ... а каким образом кривой код, который таки перестал собираться - проблема компилятора? Чего-то C99 работает на всех компилерах, без каких-либо проблем. А на различные особенности и свойства компилятора ведь и так просили не полагаться...

Иди уроки делай.

Мне лень там искать глубже, но на первой странице нет ничего, где ломается что-то, написанное на стандартном С (исключение проблемы с lto, которое ломает все). binutils и linux вообще лет 100 не собираются ничем, кроме гцц (угадай почему)

И между прочим, я на этом багтрекере чаще тебя бываю, т.к. до сих пор пытаюсь собрать ядро с -flto

Планировался переход именно на шестую ветку, но как уже сказал init_6 - слишком много говна еще надо было разгрести, а оставаться на 4.9 - это уже попахивает некрофилией, плюс смена дефолтного C++ ABI уже не просто вежливо стучалась в дверь, а просто требовалась - например тому же boost

А что там с 7.1?

Ядро собирается +- нормально...

Пока мало репортов, но баг как минимум на 7.0 уже есть

у меня все собралось 6

binutils-2.28 спокойно собирается LLVM/Clang 4.0.

В погоне за гцц шланг вобрал в себя _почти_ все костыли и расширения, так что не удивлен... но шланг 3.8 у меня ниасилил непатченый 2.27...

Ты же на бсд сидишь? там разве не патченные сорцы собирают?

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

Для порта binutils-2.28 патчи касаются только архитектур MIPS, SPARC и AArch64. Для архитектуры x86-64 патч в две строки - наложение условного определения типов в safe_ctype.h.

да, всё работает с GCC-6.3.0