Erreur ldconfig: n’est pas un lien symbolique
En cours d’exécution:
sudo /sbin/ldconfig l’erreur suivante apparaît:
/sbin/ldconfig: /usr/local/lib/ is not a symbolic link
Lorsque je lance le fichier:
file /usr/local/lib/ /usr/local/lib/: directory
Dans /usr/local/lib/ il y a trois bibliothèques que j’utilise. Je les appellerai ici lib1 , lib2 et lib3 .
- Pourquoi utiliser des outils de génération comme Autotools lorsque nous pouvons simplement écrire nos propres makefiles?
- Faire des commandes d’impression cmake avant de les exécuter
- Y a-t-il un moyen de substituer \ avec / pour les objectives de commande de Gnu?
- La commande addprefix n’est pas reconnue dans le makefile en utilisant les fenêtres nmake.exe
- Comment faire pour obtenir des fichiers cpp de différents répertoires compilés dans un seul dossier?
Maintenant, quand je fais un ldd sur mon binary, il en résulte:
lib1.so => not found lib2.so => not found lib3.so => /usr/local/lib/lib3.so (0x00216000)
Mais tous sont dans le même dossier que /usr/local/lib/{lib1,lib2,lib3}.so .
Chaque fois que je lance ldconfig , la même erreur apparaît:
/usr/local/lib/ is not a symbolic link
Je pensais que /usr/local/lib devrait être déclaré deux fois dans /etc/ld.conf.d/*.conf , mais pas:
sudo egrep '\/usr\/local' /etc/ld.so.conf.d/* projectA.conf.old:/usr/local/projectA/lib local.conf:/usr/local/lib
/etc/ld.so.conf.d/*.conf n’inclut que ld.so.conf , donc ce *.old n’est pas traité et fait référence à /usr/local/projectA/lib .
Après un certain temps, j’ai supprimé tous les fichiers lib1 et lib2 (à un moment donné, je l’ai testé sur le dossier binary), la même erreur s’est produite.
- Quelle est la manière la plus fiable d’utiliser GNUMake avec des noms de fichiers contenant des espaces?
- Windows supprime le fichier exécutable lors de son exécution. Pourquoi?
- Comment utiliser GNU Make sous Windows?
J’ai rencontré ce problème avec le client Oracle 11R2. Je ne sais pas si l’installateur Oracle a fait cela ou si quelqu’un l’a fait avant mon arrivée. Ce n’était pas 64 bits contre 32 bits, tout était 64 bits.
L’erreur était que libexpat.so.1 n’était pas un lien symbolique.
Il s’est avéré qu’il y avait deux fichiers identiques, libexpat.so.1.5.2 et libexpat.so.1 . Supprimer le fichier incriminé et en faire un lien symbolique vers la version 1.5.2 provoquait la disparition de l’erreur.
Cela signifie que vous voulez que le nom connu soit un lien symbolique vers la version actuelle. Si vous faites cela, il est peu probable que vous vous retrouviez avec une bibliothèque obsolète.
Résolu, au moins au sharepoint la question.
J’ai cherché sur le Web avant de demander, il n’y avait pas de solution concluante, la raison pour laquelle cette erreur est: lib1.so et lib2.so ne sont pas OK, très probablement pas compilé pour un PC 64, mais pour une machine 32 bits sinon lib3.so est une lib 64 bits. Au moins c’est mon hipothesis.
Malheureusement, ldconfig ne donne pas un message d’erreur clair indiquant qu’il ne pouvait pas charger la bibliothèque, il ne fait que pomper:
ldconfig: / folder_where_the_wicked_lib_is / n’est pas un lien symbolique
J’ai résolu ce problème lorsque j’ai supprimé les bibliothèques non trouvées par ldd sur le binary. Maintenant, il est plus facile de savoir où se trouve le problème.
Ma version ld: GNU ld version 2.20.51, et je ne sais pas si la version la plus récente a un meilleur message pour ses utilisateurs.
Merci.
Vous devez inclure le chemin des bibliothèques dans /etc/ld.so.conf et réexécuter ldconfig pour mettre à jour la liste
Une autre possibilité consiste à inclure dans la variable env LD_LIBRARY_PATH le chemin d’access à votre bibliothèque et à réexécuter l’exécutable.
vérifier les liens symboliques s’ils pointent vers une bibliothèque valide …
Vous pouvez append le chemin directement dans /etc/ld.so.conf, sans inclure …
ldconfig -p pour voir si votre bibliothèque est bien incluse dans le cache.
J’ai simplement exécuté la commande ci-dessous:
export LD_LIBRARY_PATH=/usr/lib/
Maintenant ça fonctionne bien.