102.3 Leçon 1

Tout comme leurs équivalents matériels, les bibliothèques logicielles sont des collections de code destinées à être utilisées par une multitude de programmes différents ; tout comme les bibliothèques physiques conservent des livres et d’autres ressources qui peuvent être utilisés par une foule de gens différents.

Pour construire un fichier exécutable à partir du code source d’un programme, deux étapes importantes sont nécessaires. Pour commencer, le compilateur transforme le code source en code machine qui est stocké dans ce qu’on appelle des fichiers objets. Ensuite, l’éditeur de liens (linker) combine les fichiers objets et les lie aux bibliothèques afin de générer le fichier exécutable final. Cette édition des liens peut se faire de manière statique ou dynamique. Selon la méthode choisie, nous parlerons de bibliothèques statiques ou, dans le cas d’une édition de liens dynamique, de bibliothèques partagées. Expliquons leurs différences.

Le nom d’une bibliothèque partagée (soname) respecte un schéma composé de trois éléments :

Voici un exemple : libpthread.so.0

En comparaison, les noms des bibliothèques statiques se terminent en .a, par exemple libpthread.a.

La glibc (GNU C library) est un bon exemple de bibliothèque partagée. Sur un système Debian GNU/Linux 9.9, son fichier est nommé libc.so.6. Ces noms de fichiers plutôt génériques sont normalement des liens symboliques qui pointent vers le fichier réel contenant une bibliothèque, dont le nom contient le numéro de version exact. Dans le cas de la glibc, ce lien symbolique ressemble à ceci :

Cette façon de référencer les fichiers de bibliothèques partagées nommés selon une version spécifique par des noms de fichiers plus généraux constitue une pratique courante.

D’autres exemples de bibliothèques partagées comprennent libreadline (qui permet aux utilisateurs de modifier les lignes de commande au fur et à mesure qu’elles sont tapées et inclut le support des modes d’édition Emacs et vi), libcrypt (qui contient des fonctions liées au chiffrement, au hachage et à l’encodage), ou libcurl (qui est une bibliothèque de transfert de fichiers multiprotocole).

Voici les emplacements habituels des bibliothèques partagées dans un système Linux :

Les références contenues dans les programmes liés dynamiquement sont résolues par le chargeur de liens dynamiques (ld.so ou ld-linux.so) lorsque le programme est exécuté. Le chargeur de liens dynamiques recherche les bibliothèques dans une série de répertoires. Ces répertoires sont spécifiés par le chemin des bibliothèques. Le chemin des bibliothèques est configuré dans le répertoire /etc, à savoir dans le fichier /etc/ld.so.conf et, plus couramment de nos jours, dans les fichiers qui se trouvent dans le répertoire /etc/ld.so.conf.d. Normalement, le premier ne comprend qu’une seule ligne include pour les fichiers *.conf dans le second :

Le répertoire /etc/ld.so.conf.d contient des fichiers *.conf :

Ces fichiers *.conf doivent inclure les chemins absolus vers les répertoires des bibliothèques partagées :

La commande ldconfig se charge de lire ces fichiers de configuration, de créer l’ensemble des liens symboliques ci-dessus qui aident à localiser les différentes bibliothèques et enfin de mettre à jour le fichier cache /etc/ld.so.cache. Ainsi, ldconfig doit être exécuté chaque fois que des fichiers de configuration sont ajoutés ou mis à jour.

Voici quelques options utiles pour ldconfig :

Si nous faisons un listing détaillé de /lib/x86_64-linux-gnu/libfuse.so.2, nous voyons la référence au fichier d’objet partagé réel libfuse.so.2.9.7 stocké dans le même répertoire :

En complément des fichiers de configuration décrits ci-dessus, la variable d’environnement LD_LIBRARY_PATH peut être utilisée pour ajouter temporairement de nouveaux chemins pour les bibliothèques partagées. Elle est constituée d’un ensemble de répertoires séparés par deux points (:) où les bibliothèques sont recherchées. Par exemple, pour ajouter /usr/local/mylib au chemin des bibliothèques dans la session shell courante, vous pouvez taper :

Vous pouvez maintenant vérifier sa valeur :

Pour ajouter /usr/local/mylib au chemin des bibliothèques dans la session shell actuelle en l’exportant vers tous les processus enfants créés à partir de ce shell, vous devez taper :

Pour supprimer la variable d’environnement LD_LIBRARY_PATH, il suffit de taper :

Pour rendre les changements permanents, vous pouvez écrire la ligne

dans un des scripts d’initialisation de Bash tels que /etc/bash.bashrc ou ~/.bashrc.

Pour rechercher les bibliothèques partagées requises par un programme spécifique, utilisez la commande ldd suivie du chemin absolu vers le programme. Le résultat indique le chemin du fichier de la bibliothèque partagée ainsi que l’adresse mémoire hexadécimale à laquelle il est chargé :

De même, nous utilisons ldd pour rechercher les dépendances d’un objet partagé :

Avec l’option -u (ou --unused), ldd affiche les dépendances directes inutilisées (si elles existent) :

La présence de dépendances inutilisées est liée aux options utilisées par l’éditeur de liens lors de la construction du binaire. Même si le programme n’a pas besoin d’une bibliothèque inutilisée, il a quand même été lié et étiqueté comme NEEDED (requis) dans les informations sur le fichier objet. Vous pouvez explorer ce sujet en utilisant des commandes comme readelf ou objdump, que vous utiliserez bientôt dans l’exercice d’approfondissement.