Gentoo, версии gcc

>Как так?

А что странного? Это уже другая ветка, вообще-то. В системе может быть одновременно и gcc 4.4, и gcc 4.5. А замаскировать пакет старой версии могут из-за какого-то серьёзного бага, исправленного в новой версии.

Так каким лучше пользоваться?

>Так каким лучше пользоваться?

Смотря для чего. В новых версиях запиливают более крутые оптимизации, поэтому, если это представляет интерес, можно заюзать последнюю версию. Если это не нужно — можно вообще компилятор не обновлять, пока через несколько лет какая-то программа перестанет собираться. У меня стоит самый свежий gcc из ~x86, всё нормально работает.

Тем, который работает

Нет, меня что смущает:
У меня стаял gcc 4.5 из arch. при «обновлении» gcc до ~arch, emerge притащил мне версию 4.4, поставил ее в слот и установил, как основную.
Если сделать emerge --prune gcc, то он удалит версию из ~arch, оставит из arch. Спрашивается: а нифага emerge поставил более старую версию? Может, gcc 4.5 плохо работает с веткой ~arch?

Видимо, разработчиками не подразумевалось, что emerge будет так делать, и версия gcc 4.5 предназначена для обоих веток...

>Так каким лучше пользоваться?

4.5.*

>Может, gcc 4.5 плохо работает с веткой ~arch?

emerge об этом всё равно не знает.

при «обновлении» gcc до ~arch, emerge притащил мне версию 4.4, поставил ее в слот и установил, как основную.

Возможно, в @world записан не sys-devel/gcc, а, например, sys-devel/gcc:4.4, если уже был установлен gcc 4.4 более старой версии, или что-то ещё.

gcc 4.4.6, кстати, у меня почему-то в package.mask. Не помню, зачем я его туда занёс, но это было не просто так.

а что, 4.5.* в кои-то веки в arch перенесли?

//ушел обновляться

Кстати, где-нибудь есть хорошее руководство по грамотной настройке lto graphite и прочик багогенных вещей?

gcc-config установкой умолчательной версии занимается, а не портеж

devl547@localhost ~ $ eix gcc -cI
sys-devel/gcc (4.6.1-r1(4.6)@09/11/11)

Ставь)

С -flto далеко не все собирается, по крайней мере в 4.5.3. И совсем не работает distcc...

из оверлеев не хочу )

из оверлеев не хочу )

Слоупочишь?

madcore@madhome ~/kvm $ eix -I sys-devel/gcc
[I] sys-devel/gcc
     Available versions:  
        (2.95)  2.95.3-r9 ~2.95.3-r10!s
        (3.1)   3.1.1-r2
        (3.2)   **3.2.2!s 3.2.3-r4
        (3.3)   ~3.3.6-r1!s
        (3.4)   3.4.6-r2!s
        (4.0)   ~*4.0.4!s
        (4.1)   4.1.2!s
        (4.2)   ~4.2.4-r1!s
        (4.3)   ~4.3.3-r2!s 4.3.4!s ~4.3.5!s ~4.3.6-r1!s
        (4.4)   ~4.4.2!s ~4.4.3-r3!s 4.4.4-r2!s 4.4.5!s ~4.4.6-r1!s
        (4.5)   ~4.5.1-r1!s ~4.5.2!s 4.5.3-r1!s
        (4.6)   [M]**4.6.0!s [M]**4.6.1-r1!s

ммм... так он даже как ~arch не отмечен

дык /etc/portage/package.unmask и package.keywords в зубы и впиред

это понятно, я к тому, что все ли с ним соберется, и как он вообще будет работать

https://bugs.gentoo.org/buglist.cgi?quicksearch=gcc 4.6

https://bugs.gentoo.org/show_bug.cgi?id=346809

...

Кстати, как из себф paludis?

>Кстати, как из себф paludis?

Поюзал немного на одной Генте, но с переходом на KDE на другой Генте и выпиливанием первой почему-то перестал. Наверное, потерялась нужда в ‘cave import’ — единственном для меня преимуществе paludis'а. А так нормальный менеджер пакетов, но с точки зрения пользователя больше преимуществ я не нашёл.

Я тоже не нашел пока причин его ставить. Оверлеи почти не использую, а для запросов есть eix.

В оверлее jeanfactoryroy есть новейший GCC 4.6.1.

>для запросов есть eix

Кстати, более годного поиска я не видел, и использовал eix даже с paludis. В paludis поиск страшно медленный, а eix — почти мгновенный.

плюсую eix. Очень удобный, и вывод приятный