LINUX.ORG.RU

gentoo: Failed to emerge dev-libs/ppl-0.12.1


0

1

Люди добрые, помогите...
Удалил я не так давно Chromium со всеми зависимостями, по причине того, что не хотелось из-за обновленного icu пересобирать еще и хромиум, (когда тестировал разные ветки, когда появились глюки после того, как разрабы размаскировали 0.50ую ветку)

С icu разобрался. Всё работает. Решил снова поставить chromium и пошла пи... по кочкам столкнулся со следующим:
первый, кто собирается как зависимость к chromium - dev-libs/ppl
и вот он-то как раз таки не дает поставить мне хромиум.
gcc 4.7.1, не пересобирался. В последнее время обновились только кеды и icu, и несколько системных вещей, не связанных с компилятором.

После старта эмёржа dev-libs/ppl-0.12.1 секунд через 5 после начала собственно make'а вылетает со следующей ошибкой.

* ERROR: dev-libs/ppl-0.12.1 failed (compile phase):
* emake failed
*
* Call stack:
* ebuild.sh, line 93: Called src_compile
* environment, line 2025: Called __eapi2_src_compile
* phase-helpers.sh, line 616: Called die
* The specific snippet of code:
* emake || die «emake failed»


вырезка непосредственно ошибок make'а:
http://pastebin.com/V5eXL1yp

emerge --info '=dev-libs/ppl-0.12.1'
http://pastebin.com/qg1dETXC

emerge -pqv '=dev-libs/ppl-0.12.1'

[~] $ e -pqv '=dev-libs/ppl-0.12.1'
[ebuild N ] dev-libs/ppl-0.12.1 USE="-doc -lpsol -pch -static-libs {-test}"


cat /var/tmp/portage/dev-libs/ppl-0.12.1/temp/build.log
http://pastebin.com/tUciGAYM

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

На генту.ру наткнулся на то, что у человека с подобной ошибкой в ядре не была включена поддержка SWAP и IA32 Emulation, у меня с этим всё в порядке, да и стоял хромиум, правда ядро пересобирал, с 3.6.8 на 3.7.0 и 3.7.1, с тем же конфигом, что и 3.6.8

Ответ на: комментарий от daemonpnz

видел это, почему в официальном ебилде ppl нет epatch_user() ?
патч уже закинул, в оверлей выносить не хочется. как применить патч (всмысле как, я понимаю) в официальном ебилде после какой строки вызывать epatch ?
а далее просто замаскирую ppl, дабы он не пытался пересобраться с официального ебилда и не начал снова выдавать ошибку

linux-v0id
() автор топика
Ответ на: комментарий от daemonpnz

а что вас не устроило в -O3 ?
just google for «Compiler Tuning With Intel Ivy Bridge Processors»

многократно уже отписывался по этому поводу во многих темах.
вся система собрана в -O3 -march=corei7
сам gcc пересобран самим собою с этими флагами, и далее вся система пересобрана с этими же самыми флагами, этим gcc

всё работает, проблем никогда не было, из-за gcc и из-за этих флагов

linux-v0id
() автор топика
Ответ на: комментарий от linux-v0id

опять же повторюсь, мануал генты, где использование -O3 равняется смертному греху, был написан не в 2012 году, и уж точно не для gcc 4.7 то было написано.
на гцц 4.7.* и актуальных процессорах, никаких проблем в генте с -O3 нет

linux-v0id
() автор топика
Ответ на: комментарий от daemonpnz

Да вы, батенька, гурман и эстет, как я посмотрю.

О, так вот как сейчас поликорректно малолетних дибилов называть!

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

Делаешь

ebuild path-to-ebuild.ebuild prepare
, ручками накатываешь патч, после чего запускаешь
ebuild path-to-ebuild.ebuild install
ebuild path-to-ebuild.ebuild qmerge

daemonpnz ★★★★★
()
Ответ на: комментарий от linux-v0id

вся система собрана в -O3 -march=corei7

Для новейших Интел-процов надо так:

-march=corei7-avx -O2

всё работает, проблем никогда не было, из-за gcc и из-за этих флагов

Нюню.

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

With GCC 4.7.0 and the common computational code we commonly benchmark at Phoronix, with the versions out there now, there really is not anything to gain out of building with the Ivy Bridge target (core-avx-i) over Sandy Bridge (corei7-avx). This though will likely change as developers begin to write code that can better take advantage of these modern CPU features. The Ivy Bridge support within GCC will also continue to improve in GCC 4.8.0 and future releases.



смысла нет пересобираться в corei7-avx или core-avx-i, ждем-с gcc 4.8, и с каких пор Sandy Bridge стал новее Ivy Bridge?
corei7-avx (Sandy Bridge)
core-avx-i (Ivy Bridge)

linux-v0id
() автор топика
Ответ на: комментарий от linux-v0id

и с каких пор Sandy Bridge стал новее Ivy Bridge?

corei7-avx (Sandy Bridge)

А тебе что, разве что-то другое посоветовали?! Или ты читаешь не вдумываясь?!

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

вот именно, вчитайся!

посоветовали: corei7-avx
но он для Sandy Bridge
посоветовали с пометкой - для новейших цпу
у меня Ivy Bridge, и он новее чем Sandy Bridge!
на Ivy Bridge нужно не corei7-avx, а core-avx-i
достаточно разжевал?

linux-v0id
() автор топика

так-с, там в багтрекере кинули пропатченный ебилд, щас опробую...
вчера не проверял обновления... а сейчас:

Calculating dependencies... done!
[ebuild N ] dev-libs/libyaml-0.1.4 USE="-doc -examples -static-libs {-test}"
[ebuild U ] dev-libs/gobject-introspection-common-1.34.2 [1.32.1]
[ebuild U ] perl-core/ExtUtils-Install-1.540.0 [1.54]
[ebuild U ] virtual/perl-ExtUtils-Install-1.540.0 [1.54]
[ebuild U ] perl-core/IO-Compress-2.59.0 [2.58.0]
[ebuild U ] virtual/perl-IO-Compress-2.59.0 [2.58.0]
[ebuild U ] perl-core/ExtUtils-ParseXS-3.180.0 [3.150.0]
[ebuild U ] virtual/perl-ExtUtils-ParseXS-3.180.0 [3.150.0]
[ebuild U ] perl-core/ExtUtils-MakeMaker-6.640.0 [6.620.0-r1]
[ebuild U ] virtual/perl-ExtUtils-MakeMaker-6.640.0 [6.620.0]
[ebuild N ] dev-util/ragel-6.7-r1 USE="-vim-syntax"
[ebuild U ] dev-libs/libxml2-2.9.0-r1 [2.8.0-r4]
[ebuild N ] app-admin/eselect-ruby-20120106
[ebuild N ] dev-lang/ruby-1.8.7_p370 USE=«berkdb gdbm ncurses readline ssl -debug -doc -examples -ipv6 -libedit -rubytests -socks5 -threads -tk -xemacs»
[ebuild N ] dev-lang/ruby-1.9.3_p286 USE=«berkdb gdbm ncurses rdoc readline ssl yaml -debug -doc -examples -ipv6 -rubytests -socks5 -tk -xemacs»
[ebuild N ] dev-ruby/rubygems-1.8.24 USE="-server {-test}" RUBY_TARGETS=«ruby18 ruby19 -jruby -ree18»
[ebuild N ] virtual/rubygems-4 RUBY_TARGETS="(ruby19)"
[ebuild N ] virtual/rubygems-1 RUBY_TARGETS="(ruby18)"
[ebuild N ] dev-ruby/rake-0.9.2.2 USE="-bash-completion -doc {-test}" RUBY_TARGETS=«ruby18 ruby19 -jruby -ree18»
[ebuild N ] dev-ruby/racc-1.4.9 USE="-doc {-test}" RUBY_TARGETS=«ruby18 ruby19 -jruby»
[ebuild N ] dev-ruby/json-1.7.5 USE="-doc {-test}" RUBY_TARGETS=«ruby18 ruby19 -jruby -ree18»
[ebuild N ] dev-ruby/rdoc-3.12 USE="-doc {-test}" RUBY_TARGETS=«ruby18 ruby19 -jruby -ree18»
[ebuild U ] dev-util/gdbus-codegen-2.34.3 [2.32.4] PYTHON_TARGETS="(-python3_3)"
[ebuild U ] dev-libs/glib-2.34.3 [2.32.4-r1]
[ebuild U ] dev-libs/gobject-introspection-1.34.2 [1.32.1]
[ebuild U ] x11-libs/gdk-pixbuf-2.26.5 [2.26.4]
[ebuild U ] dev-libs/atk-2.6.0 [2.4.0]
[ebuild NS ] media-libs/gstreamer-1.0.3 [0.10.36] USE=«introspection nls orc {-test}»
[ebuild N ] app-accessibility/at-spi2-core-2.6.2-r2 USE=«introspection»
[ebuild N ] app-accessibility/at-spi2-atk-2.6.2 USE=«{-test}»
[ebuild U ] app-misc/strigi-0.7.7-r2 [0.7.7-r1]
[ebuild N ] media-gfx/graphite2-1.2.0 USE="-perl {-test}"
[ebuild N ] media-libs/harfbuzz-0.9.9 USE="-static-libs"
[ebuild U ] x11-libs/pango-1.32.5 [1.30.1]
[ebuild NS ] media-libs/gst-plugins-base-1.0.3 [0.10.36] USE=«X alsa introspection nls ogg orc pango vorbis -theora»
[ebuild N ] x11-libs/pangox-compat-0.0.2
[ebuild U ] x11-libs/gtk+-3.6.2 [3.4.4] USE="(-egl)"
[ebuild U ] x11-misc/lightdm-kde-0.3.1 [0.3.0] LINGUAS="-it% -ro%"
[ebuild U ] net-libs/glib-networking-2.34.2 [2.32.3]
[ebuild U ] net-libs/libsoup-2.40.2 [2.38.1]
[ebuild U ] net-libs/webkit-gtk-1.10.2-r300 [1.8.3-r300]
[ebuild U ] gnome-extra/zenity-3.6.0 [3.4.0] USE=«{-test%}»



да это ёп просто рождество какое-то!

linux-v0id
() автор топика

поборол сабж путём отката dev-libs/gmp-5.1.0 на 5.0.5
после этого dev-libs/ppl-0.12.1 собрался как родной.
в последствии полернул всё апгрейдом dev-libs/gmp вновь на 5.1.0
revdep-rebuild выдает что всё в порядке:
* Dynamic linking on your system is consistent... All done.
хромиум компиляется потихонечку.

всем спасибо!

linux-v0id
() автор топика
Ответ на: комментарий от linux-v0id

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

поборол сабж путём отката dev-libs/gmp-5.1.0 на 5.0.5

то есть, при каждом обновлении ppl надо будет проворачивать фокус с даунгрейдом? знатно получается, видимо, лучше его (gmp-5.1.0) замаскировать нафиг.

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

ppl вроде апрельский, ЕМНИП, гмп от 20го декабря, вроде... так что врядли ppl обновится, либо исправят gmp в ближайшее время, либо ppl исправят, но баг вроде в gmp, он не правильно регистрировал что-то там для арифметики.

linux-v0id
() автор топика
11 мая 2013 г.

Удалил ... Chromium ... по причине того, что не хотелось из-за обновленного icu пересобирать еще и хромиум

В то время как даже на арче всё просто ставилось и работало, гентоидов ждала очень тяжёлая ночь. Но им было уже не привыкать...

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

ага.. это точно. только вот я затр..лся искать более менее актуальную бету хромиума из бинарных пакетов. все оверлеи с таковыми недоступны
да и мне пофиг уже. ушел с генты так как на моем железе (а оно далеко не слабое) готовые пакеты работают с той же скоростью что и собранные (ну может сотые секунды и разные) но i7 и 32 гига оперативы мне не дают этого заметить (ноут)
а ушел на опензусю, тамблвид
только вот тут косячки с pango идиотским. гтк{2,3}-branding-openSUSE 2.36 отказываются пахать на последнем панго, в связи с этим эти 2 пакета откатываются на 2.34 и всё пипец. панго не собирается. а из-за него не ставится кернел. кто не верит начинается установка ядра, и висит на 100%, если нажать ктрл+с
вываливается в что-то подобное:
(pango-querymodules-64:24579): GLib-GObject-CRITICAL **: gtype.c:2720: You forgot to call g_type_init()

(pango-querymodules-64:24579): GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed

(pango-querymodules-64:24579): GLib-GObject-WARNING **: cannot retrieve class for invalid (unclassed) type `<invalid>'

(pango-querymodules-64:24579): GLib-GObject-CRITICAL **: g_enum_get_value: assertion `G_IS_ENUM_CLASS (enum_class)' failed

(pango-querymodules-64:24579): Pango-WARNING **: Engine reported invalid script value 2

а дрова нвидии для оптимуса.. это вообще чудо... из-за этих дров сносил зусю и переставлял уже раз 5. ставишь дрова. на генте оптимус поднимался на них сразу (без бамблби, нативно), а тут черный экран. бился и так и сяк. а потом дошло до того, что на чистую систему ставишь дрова из блоба (не из репа), и всё. хорг ругается и дает черный экран. СНОСИШЬ БЛОБ (ЧЕРЕЗ ЕГО ЖЕ ИНСТАЛЛЕР, ВРОДЕ БЫ ДОПИСАВ --uninstall) ВРОДЕ БЫ ВСЁ, НО КАКОЙ-ТО ЖОПОЙ ЛОГ ИКСОРГА ЗАБИВАЕТСЯ БРЕДОМ ЧТО НЕТ МОДУЛЯ NVIDIA,
ХОТЯ /etc/X11/xorg.conf НЕТ, СО ВСЕХ МОДУЛЬНЫХ ПАПОК ВЫНЕСЕНЫ БЛОБОВЫ МОДУЛИ К ЧЕРТЯМ. xf86-video-{intel,nouveau} пересобраны - НО ВСЁ РАВНО РУГАЕТСЯ ЧТО НЕТ МОДУЛЯ nvidia
конечно нет, ведь я его снёс, по причине того, что он не пашит, но где о нем осталась запись. я понятия не имею. поиск по nvidia уже ничего не дает. везде где был. был удален мною. ядро переставлено, модули (драйвера) хорга переставлены. сам хорг переставлен. хорг.конфигов нету, как и не было при чистой установке системы. но постоянные засёры лога о ненахождении nvidia и во время загрузки экран передергивает и он как порезанные. вверху и справа картинка разрывается, как будто меньше нативного разрешения включается. до тех пор пока не ставишь нвидия дрова (хоть с сайта, хоть с репа) этих разрывов нет и черных экранов нет

linux-v0id
() автор топика
Ответ на: комментарий от linux-v0id

кажись зусева проблема решилась...
http://opensuse.14.x6.nabble.com/current-tumbleweed-problems-td4989545.html

удалил все *-branding-openSUSE пакеты, на их места встали автоматом *-branding-upstream и вроде всё обновляется без конфликтов (версий и вендоров)

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