find | grep libc.so.6
révèle que c'est dans /lib/i386-linux-gnu/libc.so.6
, mais un script que j'exécutais s'attend à ce qu'il soit directement sous /lib
, alors pourquoi n'y a-t-il pas au moins un lien symbolique?
Est-ce que je risquerais de casser quelque chose si j'y mettais un lien symbolique?
libc.so
a été déplacé dans le cadre du travail multiarch dans Ubuntu 11.04. La raison pour laquelle il n’existe pas de lien symbolique, c’est que le but de multiarch est de permettre l’installation simultanée des versions i386
et AMD64
de libc
afin que vous puissiez exécuter plus facilement des fichiers binaires 32 bits sur 64 bits. systèmes de bits et vice versa (et d'autres situations similaires). Si le paquet libc6
contenait un lien symbolique vers le nouvel emplacement, les versions de ce paquet pour différentes architectures ne pourraient pas être installées en même temps (quelle version du lien symbolique serait dpkg
pick?), Annulant ainsi le point entier de l'exercice .
Tout ce qui code le chemin de libc.so
doit être mis à jour pour fonctionner correctement à partir de Ubuntu 11.04. Si le script dont vous parlez fait partie d'Ubuntu, veuillez signaler un bogue et ajouter la balise multiarch
.
Les bibliothèques dynamiques sont chargées par le noyau, les chemins ne sont pas codés en dur dans un programme. Un programme dit juste "j'ai besoin de libc.so.6". Le système recherche ensuite dans les chemins de bibliothèque définis dans /etc/ld.so.conf
, y compris /usr/lib
et /lib
par défaut. Ce fichier comprend des fichiers de configuration supplémentaires dans /etc/ld.so.conf.d
.
libc.so.6
peut être trouvé dans /lib/x86_64-linux-gnu/libc.so.6
en raison du chemin défini dans /etc/ld.so.conf.d/x86_64-linux-gnu.conf
:
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
Pour savoir quelle bibliothèque est chargée par un programme, utilisez ldd
comme dans ldd /bin/bash
:
linux-vdso.so.1 => (0x00007ffff1dff000)
libncurses.so.5 => /lib/libncurses.so.5 (0x00007f9d8b3b8000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9d8b1b4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9d8ae1f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9d8b61c000)
Mettre le lien symbolique ne casserait rien.
Pour obtenir une liste des répertoires recherchés, exécutez:
ldconfig -v -N | grep '^/'
-v
fait apparaître une liste de fichiers + répertoires, -N
empêche la recréation du cache (/etc/ld.so.cache
).
Ajoutez simplement un lien symbolique au fichier libc.so.6 comme suit:
Sudo ln -s /lib/i386-linux-gnu/libc.so.6 /lib/libc.so.6
Il en va de même pour les autres fichiers manquants encore présents sur le système. Dans mon cas, le fichier manquait à Matlab. Le problème a maintenant disparu.