Informations utilisateur pour UNIX glibc

La bibliothèque C fait partie des principaux composants de tout système UNIX, car elle est coresponsable de la coopération sans problème entre l'application et le processus serveur.

Par la suite, vous trouverez quelques remarques et informations de base qui vous aideront à savoir

  • si le scanner AntiVir installé concorde avec son environnement informatique et
  • où obtenir des mises à jour en cas d’inconsistances.

Contexte

Presque tous les composants d’un système UNIX (le système d’exploitation (OS) lui-même, les logiciels liés au SE et la majeure partie des applications) sont soit écrits directement dans le langage de programmation C, soit basés sur des composants écrits en C.

Les routines de base qui supportent le travail des applications se trouvent normalement dans la bibliothèque dite libc. Le travail avec des fichiers, la mémoire vive et le réseau ainsi que la gestion des processus et l’accès à tous les services fournis par le système d’exploitation en font partie.

Logiquement, ces routines ne sont pas recréées et fournies par chaque logiciel. Elles sont donc installées à un emplacement central dans le système et à tout moment disponibles pour tous les autres programmes. Depuis qu’UNIX prend en charge le concept des bibliothèques partagées ou shared libraries (comparables aux DLL sur d’autres plateformes), il est courant de repartir les applications correspondantes en tant que modules binaires à lien dynamique (dynamically linked binaries). Le système de base sur lequel repose ce concept fournit la bibliothèque C dont le lien n’est activé qu’au moment du démarrage du logiciel.

L’implémentation de cette libc que l’on retrouve le plus souvent sous Linux est glibc, dont le site Internet se trouve à l'adresse http://www.gnu.org/software/libc/libc.html. Comme pour tous les projets Open Source qui sont populaires et très répandus, ce code se trouve en permanence en phase de développement et de remaniement. Les bugs sont éliminés, les fonctionnalités élargies et les compléments implémentés. Ce processus animé effectue une comparaison permanente avec les standards généraux qui font également l’objet d’évolutions et de modifications continues.

Certaines incongruités sont ainsi quasi inévitables. Bien qu’une impression homogène, congrue, semble se présenter « à la surface », des divergences dans les zones plus profondes peuvent générer des conditions modifiées pour les applications utilisées. Le changement de sémantique peut avoir pour conséquence qu’une interface, par exemple, qui interprétait les données d'une façon déterminée, se trouve subitement soumise à des processus de traitement différents. Un autre effet possible : la modification des paramètres d’une interface provoque le changement de l’apparence et du mode de travail de ces dernières, par exemple parce que leurs fonctionnalités ont été élargies.

Pour ces raisons, la bibliothèque (son état de développement actuel et donc son comportement) est rigoureusement versionnée. Toutefois, toutes les versions en service ne sont pas compatibles entre elles dans tous les sens.

Certes, une compatibilité en amont et en aval est visée en général, mais elle peut uniquement être atteinte via des versions très similaires (et même cela n’est pas garanti). Autrement dit : de grandes avancées de compatibilité ne sont pas franchement possibles.

Qu’est-ce qu’il faut donc faire ? Si les sources du système d’exploitation et des applications sont disponibles, la traduction du système complet peut s’envisager afin d’atteindre ainsi un état cohérent. Si les applications sont fournies en tant que binaires, il faut sélectionner la version correcte lors du téléchargement. Lors des mises à jour des composants de base il faut tenir compte des éventuelles dépendances dans les composants en amont qui peuvent donc imposer également, dans certains cas, des mises à jour. Si, par exemple, un composant du système aussi essentiel que la libc est remplacé ou mis au niveau d’une version supérieure, il peut très bien s’avérer nécessaire de procéder à la mise à jour non seulement du système de base, mais encore de tous les logiciels d’application.

 

Déterminer la version de la bibliothèque ou les versions prises en charge par AntiVir

Même si cela peut paraître bizarre : pour des raisons de compatibilité et d’interopérabilité, une application en cours n’est pas en mesure d’identifier la version de la libc installée et de déterminer ainsi si elle peut fonctionner de manière générale dans l’environnement présent. L’identification de la version n’est même pas prévue dans le design de la bibliothèque (et même si certaines implémentations offrent cette fonction, cela ne signifie pas que le procédé fonctionne sur tous les autres systèmes et plateformes). Il s’agit donc du problème classique de l’œuf et de la poule : comment une application incapable de fonctionner d’elle-même, en cas d’inconsistance des versions requises et présentes, pourrait-elle démarrer et ensuite tester sa propre aptitude au fonctionnement ?

En tant que fabricant de logiciels nous ne pouvons malheureusement pas décharger nos utilisateurs des tâches décrites pour leur faciliter le travail, comme nous aurions aimé pouvoir le faire. La situation décrite ci-avant suppose que l’administrateur du réseau se charge en permanence de maintenir la consistance de l’état des logiciels installés. Personne ne peut le faire à sa place. Mais nous souhaitons au moins vous offrir un guide pour reconnaître et résoudre des problèmes.

 

Résolution de problèmes

Les remarques ci-après se réfèrent à Linux et à la bibliothèque GNU-C. Les aspects mentionnés plus haut concernent évidemment d’autres plateformes également, mais l’obligation impérative de sélectionner une des versions disponibles s’applique jusqu’à présent uniquement à l’utilisation sous Linux en association avec GNU libc.

Sur le disque dur, glibc est disponible dans un format permettant de l’utiliser en tant que « logiciel normal ». Ce n’est pas seulement utile pendant la phase de développement, mais permet aussi plus tard, lorsque le programme est terminé, de sortir des informations essentielles.

L’appel de

/lib/libc.so.6 | head -1

affiche le numéro de la version (en vérité, les informations sont nettement plus détaillées, mais le filtre les limite à la ligne comportant le numéro de la version). Si la commande entraîne une réponse du type « Accès refusé » ou si le fichier, pour d’autres raisons, n’est pas considéré comme un « programme », vous pouvez tenter de le démarrer avec la commande ci-après :

/lib/ld-linux.so.2 /lib/libc.so.6 | head -1

Pour les numéros de version commençant par 2.0 ou 2.1, il faut utiliser les archives de notre logiciel indiquées par glibc20. Pour les numéros de version commençant par 2.2 ou 2.3, il faut utiliser les archives de notre logiciel indiquées par glibc22. Toutefois, libc peut également être disponible dans la version (interne) 1 et porte alors le nom de fichier libc.so.5. Même si cette implémentation n’est pas actuelle et comporte moins de fonctions, du fait de sa taille significativement inférieure (il y manque l’internationalisation), elle est souvent préférée pour des systèmes embarqués ou encore dans des programmes imposant des économies ou dont la mise à jour est hors de question.

En plus de la version GNU de la libc, d’autres implémentations sont utilisées à différentes fins telles qu'une « petite taille » ou encore une « portabilité extrême ». Or, étant donné que l’utilisation d’un tel logiciel résulte d’une décision délibérée (et non d’un « hasard » ou de l’installation d’une distribution standard), nous supposons que les administrateurs concernés ont une très bonne connaissance de leur système. De toute manière, ils respectent les points mentionnés ci-dessus et savent précisément quelle glibc correspond le mieux aux implémentations qu’ils utilisent. Ainsi ils savent également quelle archive des logiciels Avira est appropriée à leur cas.

Dans le cas exceptionnel où le fichier avec l’implémentation libc ne se trouve pas dans le répertoire lib, l’administrateur saura en principe où le trouver. En cas de doute, le loader d’un système en service saura lui où trouver ces objets partagés. La commande

ldd /bin/ls (ou un autre programme à lien dynamique)

pourra aider en cas de doute pour rechercher des lignes comportant libc (ou ldlinux dans le cas de figure décrit plus haut d'une bibliothèque qui ne démarre pas en tant que programme).

 

Résumé

Les programmes externes n’apportent « que » la logique high level d’une application et recourent pour les fonctions low level à des composants du système tels que libc. En cas de discordance entre ces deux composants, le logiciel sera incapable de fonctionner correctement (en sachant que l’éventail des problèmes peut aller de « semble fonctionner » via « fonctionne parfois, mais souvent ne fonctionne pas » et « ne fonctionne jamais, ne fait rien du tout » jusqu’à « reformate mon disque dur, me donne des boutons et fait que mon chat me déteste »).

Un logiciel d’application est incapable d’effectuer le test de compatibilité de manière satisfaisante, ce qui impose impérativement l’intervention de l’administrateur pour assumer la responsabilité de la consistance et de l’aptitude au fonctionnement du système. Etant donné que nous proposons nos versions pour Linux en différentes variantes pour différents environnements, un choix s’impose en fonction de la bibliothèque C installée.

Les commandes ci-après permettent d’afficher le chemin d’accès complet vers la bibliothèque C installée sur le disque dur de même que la version de l’implémentation utilisée :

$ ldd /bin/ls /bin/bash /usr/bin/vi

/bin/ls:

librt.so.1 => /lib/librt.so.1 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x40030000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40160000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

/bin/bash:

libdl.so.2 => /lib/libdl.so.2 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x40022000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

/usr/bin/vi:

libncurses.so.5 => /lib/libncurses.so.5 (0x4001e000)
libgpm.so.1 => /usr/lib/libgpm.so.1 (0x40066000)
libdl.so.2 => /lib/libdl.so.2 (0x4006c000)
libperl.so.1 => /usr/lib/libperl.so.1 (0x4006f000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4016f000)
libutil.so.1 => /lib/libutil.so.1 (0x4019c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4019f000)
libm.so.6 => /lib/libm.so.6 (0x401f0000)
libc.so.6 => /lib/libc.so.6 (0x40213000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

$ /lib/libc.so.6 | head -1
GNU C Library stable release version 2.3.1, by Roland
McGrath et al.

Produits concernés

  • Avira AntiVir MailGate [Linux]
  • Avira AntiVir MailGate [Solaris]
  • Avira MailGate Suite [Linux]
  • Avira WebGate Suite [Linux]
  • Avira WebGate Suite [Solaris]
  • Avira AntiVir Professional [Linux]
  • Avira AntiVir Professional [Solaris]
  • Avira AntiVir Server [Linux]
  • Avira AntiVir Server [Solaris]
  • Créé le : mercredi 14 mars 2007
  • Dernière MAJ: lundi 21 mars 2011
  • Evaluer l’article
Ceci vous a-t-il été utile ?