Que signifie l'erreur "no version information available" de l'éditeur de liens dynamiques de Linux ?

Question

Dans notre produit, nous fournissons des binaires linux qui se lient dynamiquement à des bibliothèques système comme "libpam". Sur certains systèmes clients, nous obtenons l'erreur suivante sur stderr lorsque le programme s'exécute :

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

L'application fonctionne bien et exécute le code de la bibliothèque dynamique. Il ne s'agit donc pas d'une erreur fatale, mais d'un simple avertissement.

Je suppose que cette erreur provient de l'éditeur de liens dynamiques lorsque la bibliothèque installée par le système manque d'un élément attendu par notre exécutable. Je ne connais pas grand-chose aux mécanismes internes du processus d'édition de liens dynamiques... et la recherche sur Google ne m'aide pas beaucoup :(

Quelqu'un sait-il ce qui provoque cette erreur ? ... comment je peux en diagnostiquer la cause ? ... et comment nous pourrions modifier nos exécutables pour éviter ce problème ?

Mise à jour : Le client a effectué une mise à niveau vers la dernière version de debian "testing" et la même erreur s'est produite. Il ne s'agit donc pas d'une bibliothèque libpam périmée. Je suppose que j'aimerais comprendre ce dont se plaint l'éditeur de liens ? Comment puis-je rechercher la cause sous-jacente, etc.

Answer 1

La mention "aucune information de version disponible" signifie que le numéro de version de la bibliothèque est inférieur à celui de l'objet partagé. Par exemple, si le numéro major.minor.patch est 7.15.5 sur la machine où vous construisez le binaire, et que le numéro major.minor.patch est 7.12.1 sur la machine d'installation, ld affichera l'avertissement.

Vous pouvez résoudre ce problème en compilant avec une bibliothèque (en-têtes et objets partagés) qui correspond à la version des objets partagés fournie avec votre système d'exploitation cible. Par exemple, si vous allez installer sur RedHat 3.4.6-9, vous ne voulez pas compiler sur Debian 4.1.1-21. C'est l'une des raisons pour lesquelles la plupart des distributions sont livrées pour des numéros de distro linux spécifiques.

Sinon, vous pouvez établir un lien statique. Cependant, vous ne voulez pas faire cela avec quelque chose comme PAM, vous voulez donc installer réellement un environnement de développement qui correspond à l'environnement de production de votre client (ou au moins installer et lier contre les versions correctes des bibliothèques).

Le conseil qui vous est donné de renommer les fichiers .so (en les complétant par des numéros de version) provient d'une époque où les bibliothèques d'objets partagés n'utilisaient pas de symboles versionnés. Ne vous attendez donc pas à ce que jouer avec le schéma de nommage .so.n.n.n vous aide (beaucoup - cela pourrait vous aider si votre système a été détruit).

Votre dernière option sera de compiler avec une bibliothèque avec un numéro de version mineur différent, en utilisant un script de liaison personnalisé : http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/scripts.html

Pour ce faire, vous devrez écrire un script personnalisé, et vous aurez besoin d'un installateur personnalisé qui exécute ld contre les objets partagés de votre client, en utilisant le script personnalisé. Cela nécessite que votre client ait gcc ou ld sur son système de production.

Answer 2

Ce message de l'éditeur de liens dynamiques de la glibc signifie en fait que la bibliothèque mentionnée ( /lib/libpam.so.0 dans votre cas) n'a pas le VERDEF ELF, tandis que la section binaire ( authpam dans votre cas) a des définitions de version dans VERNEED pour cette bibliothèque (vraisemblablement, libpam.so.0 ). Vous pouvez facilement le voir avec readelf regarde juste .gnu.version_d y .gnu.version_r les sections (ou leur absence).

Il ne s'agit donc pas d'un décalage de version de symbole, car si le binaire voulait obtenir une version spécifique par le biais de VERNEED et la bibliothèque ne l'a pas fourni dans sa version actuelle. VERDEF ce serait une erreur de liaison dure et le binaire ne fonctionnerait pas du tout (comme este par rapport à este o que ). C'est que le binaire veut certaines versions, mais la bibliothèque ne fournit aucune information sur ses versions.

Qu'est-ce que cela signifie en pratique ? En général, exactement ce que l'on voit dans cet exemple - rien, les choses fonctionnent en ignorant le versioning. Les choses peuvent-elles se casser ? Bien sûr, oui, donc les autres réponses sont correctes dans le fait que l'on devrait utiliser les mêmes bibliothèques au moment de l'exécution que celles avec lesquelles le binaire a été lié au moment de la construction.

De plus amples informations peuvent être trouvées dans Ulrich Dreppers "Version du symbole ELF" .

Answer 3

Pour info, j'ai eu ce problème en exécutant check_nrpe sur un système sur lequel était installé le système de surveillance zenoss. Pour ajouter à la confusion, cela fonctionnait bien en tant qu'utilisateur Root mais pas en tant qu'utilisateur zenoss.

J'ai découvert que l'utilisateur de zenoss avait un LD_LIBRARY_PATH qui lui faisait utiliser les bibliothèques de zenoss, qui émettent ces avertissements. Par exemple :

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
(...)

Quoi qu'il en soit, ce que j'essaie de dire, c'est qu'il faut également vérifier vos variables telles que LD_LIBRARY_PATH, LD_PRELOAD, etc.

Answer 4

Comment compilez-vous votre application ? Quels drapeaux de compilation ?

D'après mon expérience, lorsque vous ciblez le vaste domaine des systèmes Linux, construisez vos paquets sur la plus ancienne version que vous êtes prêt à supporter, et comme la plupart des systèmes ont tendance à être rétrocompatibles, votre application continuera à fonctionner. En fait, c'est la raison d'être des versions de bibliothèques - assurer la compatibilité ascendante.

Answer 5

Avez-vous vu este déjà ? La cause semble être une très vieille libpam sur l'un des côtés, probablement sur ce client.

Ou les liens pour la version peuvent être manquants : http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html