LINUX.ORG.RU

(gentoo) Не собирается dev-perl/Pango-1.223.0 . Пишет, что не файл не найден, хотя файл есть и права есть

 


0

1

Ситуация происходит при переводе десктопа (пересборка мира) с stable(amd64) на testing (~amd64) при использовании ветки hardened/linux/amd64
в eselect.

Не собирается пакет dev-perl/Pango-1.223.0 .

Может ли это как-либо быть связано с песочницей? SELinux'а нет.

dev-perl/Pango-1.222.0 уже установлен, но не пересобирается с той же ошибкой, что и dev-perl/Pango-1.223.0 .

Самое плохое, что от этого пакета собирается dev-perl/gtk2-perl, из-за которого не собирается куча приложений. Сам же пакет dev-perl/Pango не собирается по причине:
Pre-requisites not found:
Can't load '/usr/lib64/perl5/vendor_perl/5.16.1/x86_64-linux/auto/Cairo/Cairo.so' for module Cairo: libudev.so.0: невозможно открыть разделяемый объектный файл: Нет такого файла или каталога at /usr/lib64/perl5/5.16.1/x86_64-linux/DynaLoader.pm line 190.
at (eval 16) line 1.

При этом файл /usr/lib64/perl5/vendor_perl/5.16.1/x86_64-linux/auto/Cairo/Cairo.so есть. dev-perl/Cairo собран последней версии. Даже если поставить права 777 на файл, ошибка не исчезает.

Проблему не решают также:
emerge -av dev-perl/extutils-pkgconfig
perl-cleaner all

При этом при пересборке dev-perl/gtk2-perl-1.242.0 (уже установленного, стабильного) возникает ошибка (эта же ошибка возникает при пересборке нестабильного dev-perl/gtk2-perl-1.244.0):
* Using ExtUtils::MakeMaker
* perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor INSTALLMAN3DIR=none DESTDIR=/var/tmp/portage/dev-perl/gtk2-perl-1.244.0/image/
Can't locate Pango.pm in @INC (@INC contains: /etc/perl /usr/local/lib64/perl5/5.16.1/x86_64-linux /usr/local/lib64/perl5/5.16.1 /usr/lib64/perl5/vendor_perl/5.16.1/x86_64-linux /usr/lib64/perl5/vendor_perl/5.16.1 /usr/local/lib64/perl5 /usr/lib64/perl5/vendor_perl /usr/lib64/perl5/5.16.1/x86_64-linux /usr/lib64/perl5/5.16.1 .) at (eval 10) line 1.
BEGIN failed--compilation aborted at (eval 10) line 1

Заранее спасибо.

Граф equery g dev-perl/Pango
* Searching for Pango in dev-perl ...

* dependency graph for dev-perl/Pango-1.222.0
`-- dev-perl/Pango-1.222.0 amd64
`-- dev-perl/extutils-depends-0.304.0 (>=dev-perl/extutils-depends-0.300) amd64
`-- dev-perl/extutils-pkgconfig-1.130.0 (>=dev-perl/extutils-pkgconfig-1.030) amd64
`-- dev-perl/glib-perl-1.262.0 (>=dev-perl/glib-perl-1.220) ~amd64
`-- dev-perl/Cairo-1.101.0 (>=dev-perl/Cairo-1.00) ~amd64
`-- x11-libs/pango-1.30.1 (>=x11-libs/pango-1.0.0) ~amd64
`-- dev-lang/perl-5.16.1 (dev-lang/perl) ~amd64 [-build]
[ dev-perl/Pango-1.222.0 stats: packages (7), max depth (1) ]

* dependency graph for dev-perl/Pango-1.223.0
`-- dev-perl/Pango-1.223.0 amd64
`-- dev-perl/extutils-depends-0.304.0 (>=dev-perl/extutils-depends-0.300) amd64
`-- dev-perl/extutils-pkgconfig-1.130.0 (>=dev-perl/extutils-pkgconfig-1.030) amd64
`-- dev-perl/glib-perl-1.262.0 (>=dev-perl/glib-perl-1.220) ~amd64
`-- dev-perl/Cairo-1.101.0 (>=dev-perl/Cairo-1.00) ~amd64
`-- x11-libs/pango-1.30.1 (>=x11-libs/pango-1.0.0) ~amd64
`-- dev-lang/perl-5.16.1 (dev-lang/perl) ~amd64 [-build]
[ dev-perl/Pango-1.223.0 stats: packages (7), max depth (1) ]

☆☆☆

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

Честно сказать, причины ошибки я не понимаю, но попробуйте revdep-rebuild. Хуже, во всяком случае, не будет.

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

А как оно может влиять? Тут же абсолютный путь, а не относительный.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от megabaks

А куда правильнее такие вопросы задавать для быстрого получения ответа? В bugs.gentoo.org или там слоупоки? Или на англоязычный форум генты? Вы сами где сидите?

ktulhu666 ☆☆☆
() автор топика

perl-cleaner --reallyall уже прогонял?

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

Полная пересборка мира проблемы не решила.

ln -s /usr/lib/libudev.so /usr/lib/libudev.so.0 Проблему решила.

Почему-то последний sys-fs/udev создаёт только /usr/lib/libudev.so , /usr/lib/libudev.so.1 , /usr/lib/libudev.so.1.1.0 а вот нужного /usr/lib/libudev.so.0 не создаёт.

Кому писать, чтобы профиксили?

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

создавай баг на багзилле, не забудь упомянуть версии dev-perl/Pango и sys-fs/udev. Ссылку сюда - я баг побыстрее распределю кому надо

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

Почему-то последний sys-fs/udev создаёт только /usr/lib/libudev.so , /usr/lib/libudev.so.1 , /usr/lib/libudev.so.1.1.0 а вот нужного /usr/lib/libudev.so.0 не создаёт.

libfoo.so.0 и libfoo.so.1 — это такое соглашение об именовании версий библиотек. Вообще говоря, libfoo.so.X и libfoo.so.Y бинарно несовместимы друг с другом. Делать симлинк — плохо, неправильно и обязательно приведет к сегфолтам.

И если у тебя свежий portage, то после апгрейда udev'а он тебе прямо так и напишет: «не буду удалять libudev.so.0, потому что он нужен таким-то бинарникам».

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

Получается, что мне нужно поставить стабильный udev, проверить наличие /usr/lib/libudev.so.1, после чего поставить testing udev?

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

точно нет

lrwxrwxrwx 1 root 0  16 авг.  25 00:33 /usr/lib/libudev.so -> libudev.so.1.1.0
lrwxrwxrwx 1 root 0  16 авг.  25 00:33 /usr/lib/libudev.so.1 -> libudev.so.1.1.0
-rwxr-xr-x 1 root 0 67K авг.  25 00:33 /usr/lib/libudev.so.1.1.0

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

отпишись, что revdep-rebuild не помог, я баг снова открою, а то jer его уже закрыл :-)

Самое смешное, что revdep-rebuild помог. :) Просто я раньше его запускал, когда 171-r6 был установлен, а не 186. Теперь понимаю, как им правильно пользоваться.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от megabaks

Эм, прошу прощение, если ты столь очевидные замечания по поводу использования устаревших архитектур так близко к сердцу воспринимаешь.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

если поставишь портаж 2.2 или FEATURES=«preserved-rebuild» то такие проблемы будут исключены, поскольку там он будет сам следить за теми какие либы используются и не давать удалять ещё используемые и создаст виртуальный сет для тех прог, которые надо пересобрать.

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

Эм, а это нормально, что 2.2 вообще красным отмечен в eix? :) Какую лучше ставить версию, чтобы особо багов самом портаже не повылезало?

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

последняя <9999. Баги если и бывают, то весьма хитрые и обычный пользователь их не видит, а в основном там новые фичи, главное обновляться, а об этом портаж и сам напомнит.

#ifdef очень_большой_секрет 2.2 юзабельная очень давно, но если он будет ~ то со стейбла все точно поперелезают. #endif

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

а это нормально, что 2.2 вообще красным отмечен в eix?

qnikst выше всё правильно сказал - 3 года как полет нормальный на 2.2(сейчас у меня стоит sys-apps/portage-2.2.0_alpha124). На серверах правда держу stable-версию, но там и пакетов меньше, кое-что можно и вручную разгрести. На десктопе с моими экспериментами я бы точно себе что-нибудь отстрелил без preserve-libs :-)

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

Теперь проблема в том, что dev-perl/gnome2-gconf-1.44.0 собирается только c gnome-base/gconf-2.32.4, а 3.2.5 вываливает:
Can't load 'blib/arch/auto/Gnome2/GConf/GConf.so' for module Gnome2::GConf: blib/arch/auto/Gnome2/GConf/GConf.so: undefined symbol: gconf_engine_key_is_writable at /usr/lib64/perl5/5.16.1/x86_64-linux/DynaLoader.pm line 190.

Не может быть такого, что gnome2-gconf вообще не работает (а не у меня лично) с третьегномовским gconf?

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

если пакет gconf имеет слоты(не могу сейчас проверить), то скорее всего да

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

Ну, написано же: libudev.so.0. udev небось обновил.

При unmasked ~amd64 сейчас libudev.so.1. В начале я сделал просто symlink для сборки, потом удалил symlink и запустил revdep-rebuild. Вот так починилося, вот она ваша гента.

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

dev-perl/gnome2-gconf-1.44.0 собирается с gnome-base/gconf-3.2.5, во всяком случае у меня. Могу посоветовать опять perl-cleaner --all и revdep-rebuild, если портаж всё ещё не новый, после этого можно будет разбираться дальше.

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

perl-cleaner --all и revdep-rebuild пишут, что всё отлично. Что делать? :3

И да: в случае автоматической заботы portage об отсутствии автоудаления нужных библиотек, revdep-rebuild не будет видеть проблем, верно? А хотелось бы, что видел и можно было пересобрать, чтобы в будущем проблем с этим пакетами не было.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

надо подумать, может что придумаю, а может и @Pinkbyte попозже появится, что полезное скажет.

про новый emerge:

a). revdep-rebuild будет видеть проблемы

б). revdep-rebuild будет не нужен, т.к. emerge как только появляются проблемы будет настойчиво предлагать прогнать emerge @preserved-rebuild, который все проблемы пофиксит.

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

после perl-cleaner --all всё отработало успешно:

perl 5.16.1, gnome2-gconf 1.44.0, gconf 3.2.5.

в /usr/lib64/perl5/vendor_perl/5.16.1/x86_64-linux/auto/Gnome2/GConf/GConf.so есть нужные символы (gconf_engine_key_is_writable), в особенностях перла не шарю, поэтому если perl-cleaner и revdep-rebuild не спасают (и не выдают ошибок), то советую запостить баг на багзиллу.

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