[Решено] Ошибка при обновлении dev-lang/python-3.2.2
irkmaver 24 февраля, 2012 - 10:27
Запустил, как обычно, "emerge -vuD @world" в начале недели, в результате питон не собирается.
Лог сборки - http://paste.pocoo.org/show/555926/
emerge --info - http://paste.pocoo.org/show/555932/
Поискал по последнему сообщению:
"Failed to build these modules:
nis"
Вроде этот баг исправили еще в 2009 году.
Куда посмотреть, что упустил?
»
- Для комментирования войдите или зарегистрируйтесь
(*)
Я увидел у вас в логе строку
*** WARNING: renaming "nis" since importing it failed: /lib64/libnsl.so.1: symbol __libc_rpc_getport, version GLIBC_PRIVATE not defined in file libc.so.6 with link time referenceУ меня в таком же логе такой строки нет.
Обратите внимание, что /lib64/libnsl* входит в sys-libs/glibc
Я выполнил
strings /lib64/libc.so.6 | grep __libc_rpc_getportи вижу, что у меня этот символ есть.А у вас профиль, видимо, Hardened, и, возможно, это повлияло на sys-libs/glibc.
Что вам посоветовать - не знаю. Заводите баг про то, что на Hardened не собирается python-3.2.2, что тут ещё можно предложить
P.S. просмотрите http://www.google.ru/search?q=%22GLIBC_PRIVATE+not+defined+in+file+libc.so.6+with+link+time+reference%22
может быть ещё что-то найдёте
P.P.S сделайте
ls -l /lib*/libc[\.-]*- возможно у вас какие-то "левые" старые файлы остались.Кроме того, оставляю вам вот это, вдруг поможет с GLIBC_PRIVATE:
$ ldd -v /lib64/libc.so.6 /lib64/ld-linux-x86-64.so.2 (0x0000003cc3000000) linux-vdso.so.1 => (0x00007fffc7dff000) Version information: /lib64/libc.so.6: ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2спасибо, посмотрим. а профиль
спасибо, посмотрим.
а профиль обычный, не hardened :-)
https://bugs.gentoo.org
https://bugs.gentoo.org
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
корень проблемы и решение
корень проблемы и решение вылезли совершенно с неожиданной стороны.
решал в свое время такую задачу - http://www.gentoo.ru/node/23643. видимо, вместо того, чтобы задать LD_PRELOAD только для приложения aus-snmp, я объявил ее глобально. в итоге, все приложения, собранные до перезагрузки сервера, линковались не на библиотеку /lib/libc.so.6, а на определенную LD_PRELOAD.
после недавнего обновления glibc до 2.14.1, система поломалась глобально - ошибки при запуске очень многих программ о том, что не найдена версия libc.so от glibc 2.14 по пути, ранее заданному LD_PRELOAD. переопределение LD_PRELOAD не помогло, в качестве временного решения скопировал библиотеку из "правильного" места в "неправильное". программы стали запускаться, новый питон собрался.
теперь стоит задача - уйти от линковки на библиотеку по неверному пути. поможет ли полный пересбор системы (emerge -e @world)?
Должен помочь.
Должен помочь.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Вначале пересобрал мир просто
Вначале пересобрал мир просто командой "emerge -e @world", ldd все равно показывал линковку бинарных файлов по неверному пути. После этого без перезагрузки системы объявил глобально переменную LD_PRELOAD="/lib/libc.so.6" и опять полную пересборку мира. ldd опять же показывает линковку по неправильному пути, но после удаления библиотеки из неверного расположения, начал показывать на библиотеку /lib64/libc.so.6 и все работало. После перезагрузки системы опять же все работает, но на всякий случай сделал последнюю пересборку системы и повторную перезагрузку - все работает. Вот так - сам себе создал проблему на ровном месте.