Bibliothèques statiques et partagées

Une bibliothèque est un ensemble de fichiers objets compilés que vous pouvez réutiliser dans plusieurs programmes sans recompiler le code source à chaque fois.

Le langage C en distingue deux types :

• Les bibliothèques statiques (.a), copiées dans l’exécutable lors de l’édition de liens
• Les bibliothèques partagées (.so), chargées au moment de l’exécution

Les deux types commencent par des fichiers objets. Compilez vos sources avec -c comme d’habitude.

Ces fichiers .o sont la matière première que l’archiveur ou l’éditeur de liens regroupera.

L’archiveur ar regroupe les fichiers objets dans une archive .a. Le nom conventionnel est lib<name>.a.

Les options signifient : r insérer, c créer si nécessaire, s écrire un index.

Utilisez -L pour le répertoire de recherche et -l pour le nom de la bibliothèque (en retirant le préfixe lib et le suffixe .a).

Le code nécessaire est copié dans l’exécutable, qui peut ensuite fonctionner de manière autonome.

L’édition de liens statique est simple et autonome :

• L’exécutable contient tout : aucune dépendance à l’exécution
• Mais chaque programme qui en contient une copie produit des binaires plus volumineux
• Corriger un bogue dans une bibliothèque nécessite de refaire l’édition de liens de chaque programme qui l’utilise

Les bibliothèques partagées peuvent être chargées à n’importe quelle adresse mémoire : leur code doit donc être indépendant de la position. Compilez avec -fPIC.

Cela produit du code qui utilise un adressage relatif plutôt que des adresses fixes.

Construisez le fichier .so avec -shared. La convention est lib<name>.so.

Contrairement à une archive statique, il s’agit d’un véritable objet lié que le chargeur peut mapper au moment de l’exécution.

L’édition de liens est identique à celle du cas statique. La différence est que le code n’est pas copié : seule une référence est enregistrée.

L’exécutable reste petit, mais il dépend désormais de la présence de libmymath.so au moment de l’exécution.

Au démarrage, le chargeur dynamique recherche le fichier .so dans les chemins standard. Une bibliothèque située dans le répertoire courant ne figure pas dans cette liste.

Pour les tests, indiquez-la au chargeur avec LD_LIBRARY_PATH (Linux).

Les bibliothèques partagées échangent la simplicité contre la flexibilité :

• Une seule copie en mémoire est partagée par plusieurs programmes, ce qui économise de la RAM et de l’espace disque
• Une correction de bogue dans le fichier .so profite à tous les programmes sans refaire l’édition de liens
• Mais le programme ne démarre pas si le fichier .so est absent ou incompatible

Ce dernier risque correspond au classique « enfer des dépendances ».

Deux outils vous aident à voir avec quelles bibliothèques un binaire est lié :

• ldd app liste les bibliothèques partagées dont le chargeur aura besoin au moment de l’exécution
• nm libmymath.a liste les symboles (fonctions) contenus dans une bibliothèque

Si ldd affiche « not found », le chargeur ne peut pas trouver ce fichier .so dans son chemin de recherche.

Associez l’option à l’objectif correspondant.

Vous pouvez maintenant compiler et lier les deux types de bibliothèques :

• Statiques : ar rcs libX.a *.o, code copié dans le binaire, autonomes mais plus volumineuses
• Partagées : compilation avec -fPIC, création avec -shared, code chargé au moment de l’exécution
• Liez les deux avec -L et -l ; les bibliothèques partagées ont besoin d’un chemin de recherche à l’exécution, comme LD_LIBRARY_PATH

Vous disposez maintenant de toute la chaîne d’outils, du préprocesseur jusqu’à la compilation.