Que signifie l'erreur "pas d'informations de version disponibles" de l'éditeur de liens dynamique linux?
Dans notre produit, nous livrons des binaires Linux qui sont liés dynamiquement à des bibliothèques système telles que "libpam". Sur certains systèmes client, l'erreur suivante apparaît sur stderr lors de l'exécution du programme:
./authpam: /lib/libpam.so.0: no version information available (required by authpam)
L'application fonctionne correctement et exécute le code de la bibliothèque dynamique. Donc, ce n'est pas une erreur fatale, c'est juste un avertissement.
Je suppose que c'est une erreur qui provient de l'éditeur de liens dynamiques lorsque la bibliothèque système installée manque quelque chose que notre exécutable attend. Je ne connais pas grand chose au sujet du processus de création de liens dynamiques ... et googler le sujet n'aide pas beaucoup. :(
Quelqu'un sait ce qui cause cette erreur? ... comment puis-je diagnostiquer la cause? ... et comment nous pourrions changer nos exécutables pour éviter ce problème?
Mise à jour: le client a mis à niveau vers la dernière version de "testing" de Debian et la même erreur s'est produite. Ce n'est donc pas une bibliothèque libpam obsolète. Je suppose que je voudrais comprendre ce que l’éditeur de liens se plaint? Comment puis-je rechercher la cause sous-jacente, etc.?
Le "pas d'information de version disponible" signifie que le numéro de version de la bibliothèque est inférieur sur l'objet partagé. Par exemple, si votre numéro major.minor.patch est 7.15.5 sur la machine sur laquelle vous construisez le binaire et que le numéro major.minor.patch est 7.12.1 sur la machine d'installation, ld imprimera l'avertissement.
Vous pouvez résoudre ce problème en compilant avec une bibliothèque (en-têtes et objets partagés) correspondant à la version de l'objet partagé fournie avec votre système d'exploitation cible. Par exemple, si vous allez installer 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 avec des numéros de distribution Linux spécifiques.
Sinon, vous pouvez créer un lien statique. Toutefois, vous ne souhaitez pas utiliser cette fonctionnalité avec PAM, vous souhaitez donc installer un environnement de développement correspondant à l'environnement de production de votre client (ou au moins installer une liaison avec les versions de bibliothèque appropriées).
Des conseils vous permettant de renommer les fichiers .so (en les complétant avec des numéros de version) proviennent d'une époque où les bibliothèques d'objets partagés n'utilisaient pas de symboles versionnés. Donc, ne vous attendez pas à ce que jouer avec le schéma de nommage .so.n.n.n soit utile (beaucoup - cela pourrait être utile si votre système a été mis à la corbeille.)
Votre dernière option compilera 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- Éditeur de liens/scripts.html
Pour ce faire, vous devez écrire un script personnalisé et vous avez besoin d'un programme d'installation personnalisé qui s'exécute sur les objets partagés de votre client, à l'aide du script personnalisé. Cela nécessite que votre client ait gcc ou ld sur son système de production.
Le message de l'éditeur de liens dynamiques glibc signifie en réalité que la bibliothèque mentionnée (/lib/libpam.so.0 dans votre cas) n’a pas la section VERDEF ELF alors que le binaire (authpam dans votre cas) a quelques définitions de version dans la section VERNEED de cette bibliothèque (vraisemblablement , libpam.so.0). Vous pouvez facilement le voir avec readelf, il suffit de regarder .gnu.version_d et .gnu.version_r sections (ou leur absence).
Donc, ce n'est pas une incompatibilité de version de symbole, car si le binaire voulait obtenir une version spécifique via VERNEED et que la bibliothèque ne le fournisse pas dans sa version actuelle VERDEF, il s'agirait d'une erreur difficile de l'éditeur de liens. et le binaire ne fonctionnerait pas du tout (comme this comparé à this ou that ). C'est que le binaire veut des versions, mais la bibliothèque ne fournit aucune information sur ses versions.
Qu'est-ce que cela signifie en pratique? Habituellement, exactement ce que l’on voit dans cet exemple - rien, tout fonctionne en ignorant le versioning. Les choses pourraient-elles se briser? Bien sûr, oui, donc les autres réponses sont correctes dans le fait qu'il faut utiliser les mêmes bibliothèques au moment de l'exécution que celles auxquelles le fichier binaire était lié au moment de la construction.
Plus d'informations peuvent être trouvées dans Ulrich Dreppers "ELF Symbol Versioning" .
Fwiw, j’ai eu ce problème lors de l’exécution de check_nrpe sur un système sur lequel le système de surveillance zenoss était installé. 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 zenoss avait un LD_LIBRARY_PATH qui lui permettait d'utiliser des bibliothèques zenoss, qui émettent ces avertissements. C'est à dire:
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: vérifiez également vos variables telles que LD_LIBRARY_PATH, LD_PRELOAD, etc.
Comment compilez-vous votre application? Quels drapeaux de compilateur?
D'après mon expérience, lorsque vous ciblez le vaste monde de systèmes Linux existants, construisez vos packages sur la version la plus ancienne que vous êtes disposé à prendre en charge. De plus, étant donné que de plus en plus de systèmes ont tendance à être rétro-compatibles, votre application continuera à fonctionner. En fait, c’est la raison principale pour la gestion des versions de bibliothèque: assurer la compatibilité avec les versions antérieures.
Avez-vous vu ceci déjà? La cause semble être une très vieille libpam de l’un des côtés, probablement de ce client.
Ou les liens pour la version peuvent être manquants: http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html