LINUX.ORG.RU

Не собирается KDE в Gentoo

 , ,


0

1

Решил попробовать Настоящий Линукс©. Собрал базовую систему, решил установить KDE. Сборка kcoreaddons обламывается, говоря, что illegal instruction (полный лог тут). Был найден (не мной) этот пост, после которого я добавил -mno-aes, что не помогло. Если переткнуть SSD в десктоп и указать архитектуру ivybridge, то всё собирается, но выглядит вот так. При этом к примеру openbox собрался и запускается. Но мне не нужен Openbox, мне нужен KDE, который не собирается.

make.conf. Чуть раньше там было ещё это:

CPU_FLAGS_X86="avx f16c mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3"
Но по совету cpuid2cpuflags перенёс их в package.use, вдруг это поможет.

Процессор - i3-3110M (ноутбучный, да).

В общем, кто-нибудь знает, почему всё остальное собирается, а кеды нет?

Гента стабильная, профиль версии 17, для плазмы и системды.

UPD: как я понял, проблема в dev-qt/linguist-tools, но пересборка пакета не помогает.

UPD2: теперь вроде как проблема в dev/qtcore.

UPD3: таки да, пересобрал этот пакет, всё заработало.

UPD4: перезалил make.conf: https://pastebin.com/dwHzXdnv

Ответ на: комментарий от ozz_is_here_again
$equery b wine
 * Searching for wine ... 
app-emulation/wine-gecko-2.47-r1 (/usr/share/wine)
app-emulation/wine-mono-4.8.1 (/usr/share/wine)
app-emulation/wine-staging-4.6-r1 (/usr/lib32/wine-staging-4.6/wine)
app-emulation/wine-staging-4.6-r1 (/usr/share/wine-staging-4.6/wine)
app-emulation/wine-staging-4.6-r1 (/usr/include/wine-staging-4.6/wine)
app-emulation/wine-staging-4.6-r1 (/usr/lib64/wine-staging-4.6/wine)
app-emulation/wine-staging-4.6-r1 (/usr/lib/wine-staging-4.6/bin/wine)
app-eselect/eselect-wine-1.2.2 (/etc/eselect/wine)
^C
 
RedEyedMan4 ★★★★★ ()

Проблема может быть и в зависимостях linguist-tools.

Дай выхлоп

$ grep -m1 -A3 "vendor_id" /proc/cpuinfo
$ cpuid2cpuflags 

Я рекомендую вручную установить -march в CFLAGS/CXXFLAGS (можно на всякий случай пока убрать CPU_FLAGS_X86, хотя по идее это лишнее). Потом перекомпилить dev-qt/linguist-tools и его зависимости; можно даже грубо emerge -av1 $(qlist -IC dev-qt) (только если у тебя там qtwebkit - тогда исключи его, ибо будет компилиться вечность).

Kroz ★★★★★ ()
Последнее исправление: Kroz (всего исправлений: 1)

CPU_FLAGS_X86

Что это? Не помню, чтобы за 15 лет это где-то встречал. Может это какая-то слишком тонкая настройка, но с неё явно рано начинать, а перечисленное в ней обычно в USE висит.

Ни одна из ссылок с «пастой» не открывается

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)

Если переткнуть SSD в десктоп и указать архитектуру ivybridge

С переборкой всех зависимостей? Они немного с разными инструкциями могут оказаться собраны, для разных «-march» и не знаю как это повлияет.

grem ★★★★★ ()

CPUFLAGS слабо на что-то влияет, а вот CFLAGS было бы интереснее увидеть. Особенно флаг -O. Если -O3 или -Os, рекомендовал бы попробовать заменить на -O2.

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

-Os: На этом уровне код будет оптимизирован по объему. Он активирует все параметры -O2, которые не приводят к увеличению размера генерируемого кода. Он может быть полезным на компьютерах, которые обладают чрезвычайно ограниченным пространством жесткого диска и/или процессоры с небольшим размером кэша.

То есть, если что-то из -O2, будет приводить к увеличению объёма, то эти опции оптимизации будут отключены. Оно тебе надо?

Хотя если ты о своём ноутбучном процессоре, то может и к лучшему.

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

Именно, что я о своём ноутбучном процессоре. Ты же понимаешь, что чем больше код - больше памяти - больше кэша? Ну вот. А у меня объем кэша смешной по современным меркам, естественно, что -Os, скорее всего, даст бОльшую производительность конкретно на моей железке. Это частный случай. В любом случае, менее стабильным код не станет точно, собираться будет быстрее. А касательно скорости его выполнения - ну тут вопрос открытый, и лично у меня нет достаточных знаний, чтобы сказать однозначно - лучше или хуже оно станет. Но вот попробую, да посмотрю, что из этого получится как-нибудь, когда руки дойдут.

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

Если у тебя везде супер современные монстры, то это одно. А есть ещё и живые процессоры с 256K L2 кэша. Я надеюсь, ты понимаешь, почему gentoo на таких процессорах с -O2 будет медленнее, чем с -Os?

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

От того, что тебе кажется что ты что-то «понимаешь», это не становится правдой.

процессоры с 256K L2 кэша

Есть такой, -Ofast/O3 всегда быстрее, Os всегда звездецки медленно.

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

-Os отключает это:

-falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays

И полезно, когда мало кэша и мало ОЗУ. Ты же понимаешь, что если софтинка использует много памяти, дохера весит - то на системе максимум с 2G RAM эта софтинка будет работать несколько быстрее только потому, что ей не придётся лазить в своп? И опять же следует понимать разницу между условным webkit и условным glibc. В разных случаях будут разные результаты. То, что ты не понимаешь, о чем говоришь - я уже заметил.

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

@masteruser82841, перелогинься.

Ещё раз, домыслы и факты - это разные вещи.

не придётся лазить в своп

Даже гипотетическй сократившийся на один мегабайт размер бинаря от свопа никак не спасёт. Но он точно будет работать медленнее, потенциально в несколько раз.

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

Хочешь уменьшить потербление памяти хромым - кинь его в ограниченную memory cgroup, а не занимайся непонятным. Всю твою экономию убъёт лишняя картиночка или скрипт на странице.

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

Я не могу вспомнить, какой именно это был пакет, не уверен, что KDE. Он не собирался с -Os, но собрался с -O2.

Когда был ноутбук с сильно ограниченным накопителем, собирал систему с -Os, ещё USE="-doc" и кучу всего вырубал, чтобы поменьше места впустую тратить. А потом уже стало неактуально.

Что касается выполнения кода и кэша процессора - не думаю, что размер программного кода такую уж большую роль играет. Куда важнее конкретный алгоритм, ну и оптимизация. Код может быть большим по объёму, но он не целиком влезает в регистры и всякие там кэши, просто бережнее память использует. Но вообще я не очень в теме, конечно. Хочется загнаться и сэкономить пару микросекунд - лучше собрать и так, и так, и тестов запустить, дабы замерить.

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

У меня была попытка из-за лени (2 года debian, затем 2 mint). Но потом я на них плюнул и на этот комп тоже поставил генту год назад. Ещё и мейнтейнить пакеты начал.

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

grem ★★★★★ ()