Крашится гимп в новой слаке

Только что добрались руки ее все таки поставить, и на тебе, гимп крашится при выборе любого пункта в меню "Цвет". Грешил на урезанную установку, переставил full install тоже самое.
О чем вопиет gdb

Program received signal SIGILL, Illegal instruction.
0xb7616269 in ?? () from /usr/lib/libgegl-0.2.so.0
(gdb) bt
#0 0xb7616269 in ?? () from /usr/lib/libgegl-0.2.so.0
#1 0xb7613ff1 in gegl_operation_get_bounding_box ()
from /usr/lib/libgegl-0.2.so.0
#2 0x00001358 in ?? ()
#3 0xb7622114 in ?? () from /usr/lib/libgegl-0.2.so.0
#4 0x0876ecb0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

Кстати, в арче (ногами не бить, стоит в ознакомительных целях :-) после обновления, наскольку помню glib, гимп отваливается точно также.
Как руки править ?
ЗЫ Что самое интересное, на миксе 13.37-14, из которого сейчас пишу, где и новый gtk и новый и тот же самый гимп, он работает на "ура"

"SergMarkov" написал:

гимп крашится при выборе любого пункта в меню "Цвет".

$ gimp
(gimp:27036): Gimp-Widgets-CRITICAL **: gimp_device_info_set_device: assertion `(info->device == NULL && GDK_IS_DEVICE (device)) || (GDK_IS_DEVICE (info->device) && device == NULL)' failed

bormant написал:

Slackware64-14.0 на Fujitsu Siemens Esprimo Mobile V5505 -- не наблюдаю (повыбирал на новом пустом рисунке 640х400 большинство пунктов из меню Цвет).

Ну это, конечно, хорошо, но мне то не легче :-)
На linuxquestions еще один страдалец с тем же. Меня больше всего удивило, что и в арче после какого то обновления отвалился гимп.
Его , арч, и так и так снесу, уж больно это .., но удивительна такая одновременность.

Так и не то, чтобы не верю. Но уж больно причины (али оборудование) экзотичны:

"SergMarkov" написал:

Program received signal SIGILL, Illegal instruction.

bormant написал:

Так и не то, чтобы не верю. Но уж больно причины (али оборудование) экзотичны:[quote="SergMarkov"]Program received signal SIGILL, Illegal instruction.

На самом деле, развILLка несложная,
"цивильные" варианты:
или захардкожены инструкции, несваримые для Duron 900
или собрано с ключами, допускающими несваримый для Duron 900 код
"дикий" вариант:
или jmp na_xyz в любой его реинкарнации.

Но, судя по тому, что на штеуде не наблюдаю порочных проявлений, вероятно всё же что-то в области "цивильных", особенно если по [ip] (гусары, молчать!.. это был instruction pointer) на момент краха лежит нечто несваримое дюроном, но приемлемое для штеуда.

bormant написал:

На самом деле, развILLка несложная,
"цивильные" варианты:
или захардкожены инструкции, несваримые для Duron 900
или собрано с ключами, допускающими несваримый для Duron 900 код
"дикий" вариант:
или jmp na_xyz в любой его реинкарнации.
Но, судя по тому, что на штеуде не наблюдаю порочных проявлений, вероятно всё же что-то в области "цивильных", особенно если по [ip] (гусары, молчать!.. это был instruction pointer) на момент краха лежит нечто несваримое дюроном, но приемлемое для штеуда.

У меня вообще то скорее первое, мультимедийные вещи сейчас принялись собирать с обязательной поддержкой sse, которой в этом проце просто нет. Например darktable отказывается делать "мяу", так как требует обязательного наличия sse, которой в этом проце просто нет. НО, поскольку в миксе 13.37-14 это все работает как часы, но собрано gcc 4.5, а не 4.7, как в 14, то скорее это какой то глюк гцц
Вряд ли ключи, 486-686 должно вообще на всем работать

Да, как и предполагалось, это баг гцц. Заменил babl, gegl и gimp на собранные в миксе с гцц 4.5 и все работает Ругается, правда, на no version unformation libjpeg, но с джипегом работает нормально.
Блинн :-) теперь придется gcc 4.5 собирать на новой слаке.
PS Нет, не придется, патрик как всегда богх, а я, тоже в тех же пределах, идиот :-)
gegl.SlackBuild



# Trust defaults:
# --enable-mmx \
# --disable-sse \

"SergMarkov" написал:

Вряд ли ключи, 486-686 должно вообще на всем работать

не должен. ЕМНИП SSE в 686 отличается от той хреновины, что была в дюроне. Уже потом в интел договорились с амдшниками о совместимости. А 686 это всё-же интел, с т.з. GCC, потому вообще-то уже давно на дюроне НЕ работают пакеты для 686. Я когда-то давно тоже удивлён был. ИЧСХ работает для 585, и вроде есть какие-то ключики для АМД.

ЗЫЖ возможно я и ошибаюсь, давно это было...

drBatty написал:

не должен. ЕМНИП SSE в 686 отличается от той хреновины, что была в дюроне. Уже потом в интел договорились с амдшниками о совместимости. А 686 это всё-же интел, с т.з. GCC, потому вообще-то уже давно на дюроне НЕ работают пакеты для 686. Я когда-то давно тоже удивлён был. ИЧСХ работает для 585, и вроде есть какие-то ключики для АМД.

ЗЫЖ возможно я и ошибаюсь, давно это было...

Да нет, ну как не работают, на всех ранних слаках все работало, в т.ч и гимп. Но вроде как -686 в гцц вообще не включает sse и его надо ручками указывать ? В том дюроне только mmx, mmxext (что это такое не знаю) и свое 3dNow, но это вообще из другой оперы

"SergMarkov" написал:

Да нет, ну как не работают, на всех ранних слаках все работало, в т.ч и гимп.

ну.. помнится я сталкивался с подобным поведением.

"SergMarkov" написал:

Но вроде как -686 в гцц вообще не включает sse и его надо ручками указывать ?

вот этого я точно не знаю, за то знаю, что 686 aka iPentium III имеет SSE

The most notable difference was the addition of the SSE instruction set (to accelerate floating point and parallel calculations)

А вот в Duron'е таки SSE нет, а есть своё 3dNow ( http://en.wikipedia.org/wiki/3DNow! ), которое НЕ совместимо с SSE1. В iP4 и соотв. АМД данная проблема была решена, мало того, ЕМНИП именно тогда АМД и Интел договорились делиться друг с другом технологиями, что-бы таких EpicFail'ов больше не было. Но это было позже...

Ну да. Кстати, в гцц это далеко не первый глюк с ранними неинтеловскими процами, например включение 3dnow приводит по тестам к снижению скорости графики.

"SergMarkov" написал:

Ну да. Кстати, в гцц это далеко не первый глюк с ранними неинтеловскими процами, например включение 3dnow приводит по тестам к снижению скорости графики.

Любовь у них какая то неразделимая.. Когда с опенсорс можно что то поиметь, они его облизывают, но свое предпочитают не отдавать. Сколько раз их просили отдать полуось, каждый раз отказ. Зачем просили, правда, непонятно, чего с ней сейчас делать совершенно не ясно. Это как CDE открыли по принципу "на те, боже, что нам негоже", ведь им сейчас пользоваться просто нельзя. Так и с полуосью, когда то была куда как лучше винды, но сейчас то чего с ней делать и куда ее приткнуть. Скорее хайку когда нибудь допилят до вменяемого состояния, чем полуось куда то приспособят.