Ldconfig

De wiki.nexiat.fr
Aller à la navigation Aller à la recherche
Fiche express
Domaine Bibliothèques partagées (dynamic linker)
Commande ldconfig
Fichiers /etc/ld.so.conf, /etc/ld.so.conf.d/*.conf, /etc/ld.so.cache
Voir aussi ldd (résolution des dépendances d'un binaire)

ldconfig met à jour le cache des bibliothèques partagées utilisé par le chargeur dynamique (ld.so/ld-linux.so) au chargement des exécutables. Il scanne les répertoires déclarés, y indexe les .so trouvées et régénère /etc/ld.so.cache ainsi que les liens symboliques nécessaires (par exemple libfoo.so.1 pointant vers libfoo.so.1.2.3).

Configuration des chemins de recherche

Les répertoires standards (/lib, /usr/lib, etc.) sont toujours pris en compte. Pour ajouter un chemin non standard (une lib installée manuellement dans /opt/monapp/lib par exemple), deux façons de faire :

# Ajouter une ligne directement dans /etc/ld.so.conf
echo "/opt/monapp/lib" >> /etc/ld.so.conf

# Ou, plus propre, déposer un fichier dédié dans le répertoire d'inclusion
echo "/opt/monapp/lib" > /etc/ld.so.conf.d/monapp.conf

/etc/ld.so.conf inclut généralement /etc/ld.so.conf.d/*.conf via une directive include — c'est cette convention que suivent les paquets système pour ne pas avoir à toucher au fichier principal.

Régénérer le cache

Toute modification de /etc/ld.so.conf//etc/ld.so.conf.d/, ou l'installation d'une nouvelle lib dans un de ces chemins, doit être suivie d'un ldconfig pour que le changement soit pris en compte immédiatement (sinon il faudra attendre un redémarrage, ou un autre événement qui reconstruit le cache) :

ldconfig            # reconstruit /etc/ld.so.cache à partir des chemins configurés
ldconfig -v          # idem, en verbose : affiche chaque répertoire scanné et chaque lien créé
ldconfig -p          # n'écrit rien : liste le contenu actuel du cache (nom -> chemin complet)

ldconfig -p est l'outil de diagnostic de base pour vérifier qu'une bibliothèque est bien connue du système, sans avoir à chercher sur le disque :

ldconfig -p | grep libssl

Diagnostiquer une lib manquante avec ldd

Quand un binaire refuse de démarrer avec une erreur du type error while loading shared libraries: libfoo.so.1: cannot open shared object file, le réflexe est de croiser ldd (qui liste les dépendances résolues ou non d'un exécutable) et ldconfig -p (qui liste ce que le cache connaît réellement) :

ldd /usr/bin/monbinaire
#   libfoo.so.1 => not found

ldconfig -p | grep libfoo
# (rien : la lib n'est pas dans le cache)

Deux cas de figure classiques :

  • la lib n'est présente nulle part sur le système → il faut installer le paquet qui la fournit ;
  • la lib est présente mais dans un chemin non standard (installation manuelle, build local) → il faut l'ajouter à /etc/ld.so.conf.d/ puis relancer ldconfig (voir plus haut) — c'est le cas typique après une installation depuis les sources dans /usr/local/lib ou /opt.

Une fois la lib ajoutée au cache, ldd doit résoudre le chemin complet au lieu de not found.

Voir aussi

  • ldd — lister les dépendances dynamiques d'un binaire
  • Chkconfig — gestion des services SysV init