LINUX.ORG.RU

Несоответствие версий «GLIBC_2.11 not found» можно ли побороть?


0

0

Приветствую! Провожу пробы по кросскомпилу для WDTV Live. Делается прямо на нём. Используется образ squeeze для архитектуры mipsel. В него chroot и т.д. т.п. Далее пробуем малое - htop. конфигурится, мэйкается нормально.. после чего запускается под сквизи.. переносим на чистый WDTV Live - тоже работает.

# ldd htop 
   libncurses.so.5 => /lib/libncurses.so.5 (0x2aad8000)
   libm.so.6 => /lib/libm.so.6 (0x2ab28000)
   libc.so.6 => /lib/libc.so.6 (0x2abb4000)
   libdl.so.2 => /lib/libdl.so.2 (0x2ad18000)
   /lib/ld.so.1 (0x2aaa8000) 
Теперь пробуем посложнее transmission-daemon. конфигурится мэйкается под сквизи нормально и запускается тоже. Переносим на чистый WDTV Live получаю ошибку типа:
transmission-daemon: /lib/libc.so.6: version `GLIBC_2.11' not found (required by /transmission-daemon)
Замечено что libc.so.6 так же как в htop используется.
# ldd transmission-daemon
        librt.so.1 => /lib/librt.so.1 (0x2aad8000)
        libcurl-gnutls.so.4 => /usr/lib/libcurl-gnutls.so.4 (0x2aaf0000)
        libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x2ab48000)
        libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x2aba4000)
        libz.so.1 => /usr/lib/libz.so.1 (0x2ad28000)
        libevent-1.4.so.2 => /apps/transmission/usr/lib/libevent-1.4.so.2 (0x2ad50000)
        libm.so.6 => /lib/libm.so.6 (0x2ad7c000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x2ae08000)
        libc.so.6 => /lib/libc.so.6 (0x2ae34000)
        /lib/ld.so.1 (0x2aaa8000)
        libidn.so.11 => /usr/lib/libidn.so.11 (0x2af98000)
        liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x2afcc000)
        libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x2afec000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x2b048000)
        libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x2b088000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x2b150000)
        libdl.so.2 => /lib/libdl.so.2 (0x2b1ec000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x2b200000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x2b22c000)
        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x2b240000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x2b26c000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x2b320000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x2b358000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x2b36c000)
        libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x2b384000)
        libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x2b398000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x2b3bc000)
Попытки создать директорию с libc.so.6 взятой из сквизи и ссылка на неё в виде LD_LIBRARY_PATH приводят к сегфолту.

Вопрос: как побороть несоответствие glibc 2.11 (squeeze) и glibc 2.08 (WDTV Live)? Можно ли компилить например в сквизи но используя страрую либу 2,08 как родную или даже вообще используя все те либы которые есть для чистого ВД?


>>WDTV Live.

Что это такое?

Провожу пробы по кросскомпилу для WDTV Live. Делается прямо на нём. Используется образ squeeze для архитектуры mipsel. В него chroot и т.д. т.п. Далее пробуем малое - htop. конфигурится, мэйкается нормально.. после чего запускается под сквизи.. переносим на чистый WDTV Live - тоже работает.


То что ты делаешь - это не кросскомпиляция. Ты переносишь бинарники между системами. Примерно как поставил на 2 разные x86 машины squeeze и lenny, скомпилировал на squeeze и переносишь бинарник на lenny.
При кросскомпиляции системные библиотеки типа libc входят в состав тулчейна на инструментальной машине и в состав целевой системы. Они одинаковы и там и там.

как побороть несоответствие glibc 2.11 (squeeze) и glibc 2.08 (WDTV Live)?


Найди средства разработки которыми была собрана корневая ФС на этом твоём WDTV Live. Это самый лучший вариант. Можно ещё собирать статически. Для нескольких нужных программ это не страшно.

Попытки создать директорию с libc.so.6 взятой из сквизи и ссылка на неё в виде LD_LIBRARY_PATH приводят к сегфолту.


Если копировать то все библиотеки. А то получается /lib/ld.so.1 из системы, а libc из squeeze.

gogi
()

конпилировать следует на более старой версии glibc, чтобы избежать несовместимости сверху вниз. Или на целевую систему также ставить 2.11.

alex_custov ★★★★★
()

Ставь генту (можно в чруте) и собирай систему с такими же glibc, gcc и прочим что и на WDTV Live.

glibc 2.08 в генте есть. (или тебе нужен 2.0.8?)

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

Что это такое?

Медиаплеер. Средств разработки официально предоставленных WD нет. Рассчитывал что таки можно было бы как то привязаться при сборке в сквизи к старым либам WD-хи.. ну нет так нет. Придётся искать системку с 2.08.. хм..

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

значит он не использует те функции, которые версионированы как @GLIBC_2.11


$strings /usr/bin/htop|grep GLIBC
GLIBC_2.0
GLIBC_2.3
GLIBC_2.7
GLIBC_2.1

т.е. в моей системе ему достаточно будет GLIBC 2.7

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

Спасибо! $strings transmission-daemon | grep GLIBC GLIBC_2.0 GLIBC_2.11 GLIBC_2.7 GLIBC_2.4 GLIBC_2.3.3 GLIBC_2.3 GLIBC_2.2

Это из-под сквизи.. остается надеяться что демон захочет собираться вообще на машине с 2.8 )

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

evy ^_^ sylvia /usr/bin >objdump -T transmission-daemon |grep GLIBC_2.11
00000000 DF *UND* 00000000 GLIBC_2.11 fallocate64


можете пропатчить чтобы configure не цепляло fallocate64 из libc
получите бинарник который будет работать на 2.7

00000000 DF *UND* 00000000 GLIBC_2.7 __isoc99_sscanf

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

Еще раз гран мерси.

Получил рабочую версию, правда варварским методом (другой на ум не пришёл) - избавившись от fallocate64 вообще. Благо есть альтернативная реализация у автора.

Появилось в версии transmission 1.90 (2010/02/16):

*Use fallocate64() for fast file preallocation on systems that support it

Вот уж сомневаюсь что плеер относится к «systems that support it». Хотя что параллельно намекает на проявляющуюся в последнее время на плеерах людей проблему с фрагментацией качаемых трансмишном файлов и соответсвенно падением производительности дисковой подсистемы.

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