Назад | Перейти на главную страницу

Как можно связать одну и ту же двоичную библиотеку в дистрибутиве X с меньшим количеством библиотек, чем в дистрибутиве Y?

У меня есть сторонняя двоичная библиотека для подключения к серверу через SSL, которая отлично работает на Cent OS 4 32-разрядная, но на Debian Lenny 32-разрядная. Я получаю сообщение об ошибке инициализации SSL при попытке обработать транзакцию.

Когда я выполняю ldd в библиотеке Debian отсутствуют 5 ссылок, ldd на Cent OS есть:

libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2
libkrb5.so.3 => /usr/lib/libkrb5.so.3
libcom_err.so.2 => /lib/libcom_err.so.2
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3
libresolv.so.2 => /lib/libresolv.so.2

Я подозреваю, что моя проблема здесь. Все эти библиотеки установлены в системе Debian, поэтому я озадачен тем, что сторонний двоичный файл их не видит.

Я сделал md5sum для сторонних двоичных файлов в каждой системе, и они точно такие же.

Вот полный ldd листинг из Cent OS:

[root@localhost ~]# ldd /usr/lib/libwebpayclient.so
        libssl.so.4 => /lib/libssl.so.4 (0x0026a000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0x00c41000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00544000)
        libm.so.6 => /lib/tls/libm.so.6 (0x0093e000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00da4000)
        libc.so.6 => /lib/tls/libc.so.6 (0x0066e000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x008dd000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00394000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x00111000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00114000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x007da000)
        libdl.so.2 => /lib/libdl.so.2 (0x00135000)
        libz.so.1 => /usr/lib/libz.so.1 (0x004d1000)
        /lib/ld-linux.so.2 (0x008b5000)

Обратите внимание, что мне пришлось установить пакет compat-libstdc ++ - 33.i386 для разрешения libstdc ++. So.5

А вот и полный ldd листинг из Debian:

localhost:~# ldd /usr/lib/libwebpayclient.so
    linux-gate.so.1 =>  (0xb7fcb000)
    libssl.so.4 => not found
    libcrypto.so.4 => not found
    libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7ee5000)
    libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7ebf000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7eb2000)
    libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7d57000)
    /lib/ld-linux.so.2 (0xb7fcc000)

Обратите внимание, что мне пришлось установить пакет libstdc ++ 5, чтобы разрешить libstdc ++. So.5.

С помощью ln -s чтобы исправить 2 ссылки "не найдено", которые я получаю:

localhost:~# ldd /usr/lib/libwebpayclient.so
        linux-gate.so.1 =>  (0xb7eff000)
        libssl.so.4 => /usr/lib/libssl.so.4 (0xb7e8e000)
        libcrypto.so.4 => /usr/lib/libcrypto.so.4 (0xb7d31000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7c76000)
        libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7c50000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7c43000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7ae8000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7ae4000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7acf000)
        /lib/ld-linux.so.2 (0xb7f00000)

Что интересно, появляется libz.so.1. Вот и разгадка.

Версия SSL в Cent OS - 0.9.7a, а в Debian - 0.9.8. Бьюсь об заклад, он связан с меньшим количеством библиотек ...

Проблема заключалась в том, что версия SSL в Debian (libssl.so.0.9.8) больше не связывалась с файлами, которые были связаны с libssl.so.0.9.7a в Cent OS. Путем копирования версии CentOS в ящик Debian и исправления ссылки /usr/lib/libssl.so.4 проблема была решена. Это не идеально для целей безопасности, потому что, если Cent OS обновит этот файл, мне придется не забыть скопировать его. Для этого я подписался на советы по безопасности Cent OS 4. Надеюсь, что сторонняя компания вскоре выпустит обновленную библиотеку.

Эти ldd запускаются из идентичных (md5sums одинаковые) копий одной и той же библиотеки? Если библиотеки отсутствуют в той или иной системе, ldd должен сообщать «не найден», он не должен просто ничего не отображать.

Первоначальный список библиотек, которые требуются общему объекту (будь то библиотека или двоичный файл), жестко запрограммирован, и за исключением перекомпиляции или искажения, список никогда не изменится. Одна вещь, которая может расстроить тележку для яблок, - это то, что ldd просматривает список зависимостей библиотеки и отображает информацию о те библиотеки тоже, так что вы можете законно иметь разные списки библиотек в разных системах, потому что библиотеки, на которые указывают, имеют разные наборы включенных библиотек. Еще не запутались?

Однако, учитывая огромную разницу между двумя списками и тот факт, что у вас есть библиотеки, которых я никогда не видел (у меня нет libssl.so.4 в моих системах CentOS), я собираюсь придерживаться «нераскрытой информации» как источника ваших проблем - что-то вроде установки где-нибудь кучи дополнительных библиотек с сумасшедшей информацией о связях.

Кроме того, ваш вопрос не ясен относительно того, завершена ли первая вставка вывода ldd или "diff". Пожалуйста, включите полный вывод ldd из обеих систем с удалением всех созданных вручную символических ссылок (а также включает список символических ссылок, которые вы должны были создать, с их исходным и целевым местоположениями).