Что означает ошибка «нет информации о версии» в динамическом компоновщике Linux?

Question

В нашем продукте мы поставляем несколько бинарных файлов linux, которые динамически связываются с системными библиотеками, такими как "libpam". В некоторых клиентских системах мы получаем следующую ошибку на stderr при запуске программы:

./authpam: /lib/libpam.so.0: no version information available (required by authpam)

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

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

Кто-нибудь знает, что вызывает эту ошибку? ... как я могу диагностировать причину? ... и как мы могли бы изменить наши исполняемые файлы, чтобы избежать этой проблемы?

Обновление: клиент обновился до последней версии тестирования Debian, и произошла та же ошибка. Так что это не устаревшая библиотека libpam. Думаю, я бы хотел понять, на что жалуется компоновщик? Как я могу расследовать основную причину и т. Д.?

Answer 1

«Информация о версии недоступна» означает, что номер версии библиотеки ниже для общего объекта. Например, если ваш номер major.minor.patch равен 7.15.5 на компьютере, на котором вы создаете двоичный файл, а номер major.minor.patch - 7.12.1 на установочном компьютере, ld выведет предупреждение.

Это можно исправить, скомпилировав библиотеку (заголовки и общие объекты), которая соответствует версии общего объекта, поставляемой с вашей целевой ОС. Например, если вы собираетесь установить в RedHat 3.4.6-9, вы не хотите компилировать в Debian 4.1.1-21. Это одна из причин, по которой большинство дистрибутивов поставляются с определенными номерами дистрибутивов Linux.

В противном случае вы можете статически связать. Однако вы не хотите делать это с чем-то вроде PAM, поэтому вы действительно хотите установить среду разработки, соответствующую производственной среде вашего клиента (или, по крайней мере, установить и связать с правильными версиями библиотеки.)

Совет, который вы получаете для переименования файлов .so (с заполнением их номерами версий), вытекает из того времени, когда в библиотеках общих объектов не использовались символы версий. Поэтому не ожидайте, что игра со схемой именования .so.n.n.n поможет (во многом - это может помочь, если ваша система была перегружена).

Последний вариант будет компилироваться с библиотекой с другим второстепенным номером версии с использованием специального сценария связывания: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/scripts.html

Чтобы сделать это, вам нужно написать собственный скрипт, и вам понадобится специальный инсталлятор, который запускает ld для общих объектов вашего клиента, используя этот скрипт. Это требует, чтобы ваш клиент имел gcc или ld в своей производственной системе.

Answer 2

На самом деле это сообщение динамического компоновщика glibc означает, что упомянутая библиотека (/lib/libpam.so.0 в вашем случае) не имеет секции VERDEF ELF, в то время как двоичный файл (authpam в вашем случае) имеет некоторую версию определения в разделе VERNEED для этой библиотеки (предположительно, libpam.so.0). Вы можете легко увидеть это с помощью readelf, просто посмотрите на секции .gnu.version_d и .gnu.version_r (или их отсутствие).

Так что это не несоответствие версий символов, потому что, если двоичный файл хотел получить какую-то конкретную версию через VERNEED, а библиотека не предоставила ее в фактическом VERDEF, это было бы ошибкой жесткого компоновщика и двоичным файлом не будет работать вообще (как это по сравнению с это или то ). Дело в том, что двоичный файл хочет иметь несколько версий, но библиотека не предоставляет никакой информации о своих версиях.

Что это означает на практике? Как правило, именно то, что видно в этом примере & mdash; ничего, все просто работает без учета версий. Могут ли вещи сломаться? Конечно, да, поэтому другие ответы верны в том, что во время выполнения нужно использовать те же библиотеки, что и библиотеки, с которыми был связан бинарный файл.

Более подробную информацию можно найти в Ульрихе Дреппере "Версия ELF Symbol" .

Answer 3

Кстати, у меня была эта проблема при запуске check_nrpe в системе, в которой была установлена ​​система мониторинга zenoss. Чтобы добавить к путанице, он работал нормально как пользователь root, но не как пользователь zenoss.

Я обнаружил, что у пользователя zenoss был LD_LIBRARY_PATH, который заставил его использовать библиотеки zenoss, которые выдают эти предупреждения. То есть:

root@monitoring:$ echo $LD_LIBRARY_PATH

su - zenoss
zenoss@monitoring:/root$ echo $LD_LIBRARY_PATH
/usr/local/zenoss/python/lib:/usr/local/zenoss/mysql/lib:/usr/local/zenoss/zenoss/lib:/usr/local/zenoss/common/lib::
zenoss@monitoring:/root$ /usr/lib/nagios/plugins/check_nrpe -H 192.168.61.61 -p 6969 -c check_mq
/usr/lib/nagios/plugins/check_nrpe: /usr/local/zenoss/common/lib/libcrypto.so.0.9.8: no version information available (required by /usr/lib/libssl.so.0.9.8)
(...)
zenoss@monitoring:/root$ LD_LIBRARY_PATH= /usr/lib/nagios/plugins/check_nrpe -H 192.168.61.61 -p 6969 -c check_mq
(...)

Так или иначе, что я пытаюсь сказать: проверьте ваши переменные, такие как LD_LIBRARY_PATH, LD_PRELOAD и т.д.

Answer 4

Как вы компилируете свое приложение? Какие флаги компилятора?

По моему опыту, когда вы нацеливаетесь на обширную сферу Linux-систем, постройте свои пакеты на самой старой версии, которую вы готовы поддерживать, и поскольку больше систем имеют тенденцию к обратной совместимости, ваше приложение будет продолжать работать. На самом деле в этом и заключается вся причина создания версий библиотеки - обеспечение обратной совместимости.

Answer 5

Вы уже видели это уже? Причина, по-видимому, в том, что на одной из сторон был очень старый libpam, возможно, у этого клиента.

Или ссылки на версию могут отсутствовать: http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html