Erreur Linux lors du chargement de bibliothèques partagées: impossible d'ouvrir le fichier d'objet partagé: aucun fichier ou répertoire de ce type
Le programme fait partie de la suite de tests Xenomai, compilée à partir de PC Linux dans la chaîne d'outils Linux + Xenomai ARM.
# echo $LD_LIBRARY_PATH
/lib
# ls /lib
ld-2.3.3.so libdl-2.3.3.so libpthread-0.10.so
ld-linux.so.2 libdl.so.2 libpthread.so.0
libc-2.3.3.so libgcc_s.so libpthread_rt.so
libc.so.6 libgcc_s.so.1 libstdc++.so.6
libcrypt-2.3.3.so libm-2.3.3.so libstdc++.so.6.0.9
libcrypt.so.1 libm.so.6
# ./clocktest
./clocktest: error while loading shared libraries: libpthread_rt.so.1: cannot open shared object file: No such file or directory
Edit: OK Je n'ai pas remarqué que le fichier .1 à la fin faisait partie du nom du fichier. Qu'est-ce que cela veut dire de toute façon?
Mettre à jour
Bien que ce que j'écris ci-dessous soit vrai en tant que réponse générale à propos des bibliothèques partagées, je pense que la cause la plus fréquente de ce type de message est le fait que vous avez installé un paquet, mais pas la version "-dev" de ce paquet .
Eh bien, il ne ment pas - il n'y a pas de libpthread_rt.so.1 dans cette liste. Vous aurez probablement besoin de le reconfigurer et de le reconstruire de manière à ce que cela dépende de la bibliothèque que vous avez, ou d'installer tout ce qui fournit libpthread_rt.so.1.
Généralement, les numéros après .so sont des numéros de version et vous constaterez souvent qu'il s'agit de liens symboliques entre eux. Si vous avez la version 1.1 de libfoo.so, vous aurez un fichier réel libfoo.so.1.0, et les liens symboliques foo.so et foo.so.1 pointant vers libfoo.so.1.0. Et si vous installez la version 1.1 sans supprimer l’autre, vous aurez un libfoo.so.1.1, et libfoo.so.1 et libfoo.so pointeront maintenant vers le nouveau, mais tout code ayant besoin de cette version peut utilisez le fichier libfoo.so.1.0. Code qui s'appuie simplement sur l'API de version 1, mais ne se soucie pas de savoir si c'est 1.0 ou 1.1 spécifiera libfoo.so.1. Comme le souligne orip dans les commentaires, cela est expliqué à l’adresse http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html .
Dans votre cas, vous pouvez vous échapper avec les liens symboliques libpthread_rt.so.1 à libpthread_rt.so. Rien ne garantit que cela ne casse pas votre code et ne mange pas vos dîners télévisés, cependant.
Votre bibliothèque est une bibliothèque dynamique . Vous devez indiquer au système d'exploitation où il peut la localiser au moment de l'exécution.
Pour ce faire, nous devons suivre ces étapes simples:
(1) Trouvez l’emplacement de la bibliothèque si vous ne le connaissez pas.
Sudo find / -name the_name_of_the_file.so
(2) Vérifier l'existence de la variable d'environnement de chemin de bibliothèque dynamique (LD_LIBRARY_PATH)
$ echo $LD_LIBRARY_PATH
s'il n'y a rien à afficher, ajoutez une valeur de chemin par défaut (ou pas si vous le souhaitez)
$ LD_LIBRARY_PATH=/usr/local/lib
(3) Nous ajoutons le chemin souhaité, l'exportons et essayons l'application.
Notez que le chemin doit être le répertoire dans lequel path.so.something est . Donc, si path.so.something est dans /my_library/path.so.something, il devrait être:
$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_library/
$ export LD_LIBRARY_PATH
$ ./my_app
source: http://www.gnu.org/software/gsl/manual/html_node/Shared-Libraries.html
Voici quelques solutions que vous pouvez essayer:
ldconfig
Comme AbiusX l’a fait remarquer: Si vous venez d’installer la bibliothèque, vous devrez peut-être simplement exécuter ldconfig .
Sudo ldconfig
ldconfig crée les liens nécessaires et met en cache le plus récent fichier bibliothèques partagées trouvées dans les répertoires spécifiés dans la commande ligne, dans le fichier /etc/ld.so.conf et dans les répertoires de confiance (/ lib et/usr/lib).
Habituellement, votre gestionnaire de paquets s’occupe de cela lorsque vous installez une nouvelle bibliothèque, mais pas toujours, et exécuter ldconfig ne vous fera pas de mal, même si ce n’est pas votre problème.
Paquet de développement ou mauvaise version
Si cela ne fonctionne pas, je voudrais également vérifier la suggestion de Paul et rechercher une version "-dev" de la bibliothèque. De nombreuses bibliothèques sont divisées en packages dev et non-dev. Vous pouvez utiliser cette commande pour le rechercher:
apt-cache search <libraryname>
Cela peut également aider si vous avez simplement installé la mauvaise version de la bibliothèque. Certaines bibliothèques sont publiées simultanément dans différentes versions, par exemple Python.
Emplacement de la bibliothèque
Si vous êtes certain que le bon paquet est installé et que ldconfig ne l’a pas trouvé, il se peut qu’il se trouve dans un répertoire non standard. Par défaut, ldconfig recherche dans /lib, /usr/lib et les répertoires répertoriés dans /etc/ld.so.conf et $LD_LIBRARY_PATH. Si votre bibliothèque est située ailleurs, vous pouvez soit ajouter le répertoire sur sa propre ligne dans /etc/ld.so.conf, ajouter le chemin d'accès de la bibliothèque à $LD_LIBRARY_PATH ou déplacer la bibliothèque dans /usr/lib. Puis lancez ldconfig.
Pour savoir où se trouve la bibliothèque, essayez ceci:
Sudo find / -iname *libraryname*.so*
(Remplacez libraryname par le nom de votre bibliothèque)
Si vous choisissez la route $LD_LIBRARY_PATH, vous voudrez l'inscrire dans votre fichier ~/.bashrc pour qu'il s'exécute chaque fois que vous vous connectez:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/library
J'ai eu la même erreur, je pouvais la résoudre en donnant,
Sudo ldconfig -v
J'espère que cela t'aides.
Vous devez vous assurer que vous spécifiez le chemin de la bibliothèque lors de la création du lien Lors de la compilation de votre fichier .c:
gcc -I/usr/local/include xxx.c -o xxx -L/usr/local/lib -Wl, -R/usr/local/lib
La partie -Wl, -R indique au binaire résultant de rechercher également la bibliothèquein/usr/local/lib au moment de l'exécution avant d'essayer d'utiliser celui de/usr/lib /
J'espère que cela vous aidera.
La page de référence de linux.org explique la mécanique, mais n’explique aucune des motivations qui la sous-tendent :-(
Pour cela, voir Guide de Sun Linker and Libraries
De plus, notez que le "contrôle de version externe" est largement obsolète sous Linux, car le contrôle de version de symbole (extension GNU) vous permet de disposer de plusieurs versions incompatibles de la même fonction dans une même bibliothèque. Cette extension permettait à la glibc d’avoir la même version externe: libc.so.6 pour les 10 dernières années.
Essayez d’ajouter LD_LIBRARY_PATH, qui indique les chemins de recherche, à votre fichier ~/.bashrc.
LD_LIBRARY_PATH=path_to_your_library
Ça marche!
cd /home/<user_name>/
Sudo vi .bash_profile
ajouter ces lignes à la fin
LD_LIBRARY_PATH=/usr/local/lib:<any other paths you want>
export LD_LIBRARY_PATH
Une autre solution possible en fonction de votre situation.
Si vous savez que libpthread_rt.so.1 est identique à libpthread_rt.so, vous pouvez créer un lien symbolique en:
ln -s /lib/libpthread_rt.so /lib/libpthread_rt.so.1
Alors ls -l /lib devrait maintenant montrer le lien symbolique et ce à quoi il pointe.
Si vous exécutez votre application sous Microsoft Windows, le chemin d'accès aux bibliothèques dynamiques (.dll) doit être défini dans la variable d'environnement PATH.
Si vous exécutez votre application sous UNIX, le chemin d'accès à vos bibliothèques dynamiques (.so) doit être défini dans la variable d'environnement LD_LIBRARY_PATH.
Tout ce que j'avais à faire était de courir:
Sudo apt-get install libfontconfig1
J'étais dans le dossier situé à /usr/lib/x86_64-linux-gnu et cela a fonctionné parfaitement.
J'ai eu cette erreur lors de l'exécution de mon application avec Eclipse CDT sur Linux x86.
Pour résoudre ce problème:
- Dans Eclipse:
Exécuter en tant que -> Exécuter les configurations -> Environnement
Définir le chemin
LD_LIBRARY_PATH=/my_lib_directory_path
J'ai eu une erreur similaire et cela n'a pas été résolu en donnant LD_LIBRARY_PATH dans ~/.bashrc . Ce qui a résolu mon problème est d'ajouter un fichier .conf et de le charger . Allez au terminal et soyez en su.
gedit /etc/ld.so.conf.d/myapp.conf
Ajoutez votre chemin de bibliothèque dans ce fichier et sauvegardez-le (par exemple: /usr/local/lib).Vous devez exécuter la commande suivante pour activer le chemin:
ldconfig
Vérifiez votre nouveau chemin d'accès à la bibliothèque:
ldconfig -v | less
Si cela montre vos fichiers de bibliothèque, alors vous êtes prêt à partir.
essayez d'installer Sudo lib32z1
Sudo apt-get install lib32z1
L'erreur se produit car le système ne peut pas faire référence au fichier de bibliothèque mentionné. Suivez les étapes suivantes:
- Lancer
locate libpthread_rt.so.1listera le chemin de tous les fichiers portant ce nom. Supposons qu'un chemin est/home/user/loc. - Copiez le chemin et exécutez
cd home/USERNAME. Remplacez USERNAME par le nom de l'utilisateur actif en cours avec lequel vous voulez exécuter le fichier. - Exécutez
vi .bash_profileet à la fin du paramètreLD_LIBRARY_PATH, juste avant., ajoutez la ligne/lib://home/usr/loc:.. Enregistrez le fichier. - Fermez le terminal et redémarrez l'application. Ça devrait fonctionner.
problème similaire trouvé ici: https://bugzilla.redhat.com/show_bug.cgi?id=1456202 J'ai essayé la solution mentionnée et cela fonctionne réellement.
Les solutions dans les questions précédentes peuvent fonctionner. Mais je pense que c'est un moyen facile de le réparer. Essayez de réinstaller le paquet libwbclient dans Fedora:
dnf reinstall libwbclient
J'ai eu cette erreur et je pense que c'est la même raison que la tienne
error while loading shared libraries: libnw.so: cannot open shared object
file: No such file or directory
Essaye ça. Correction des autorisations sur les fichiers:
cd /opt/Popcorn (or wherever it is)
chmod -R 555 * (755 if not ok)
chown -R root:root *
“Sudo su” pour obtenir des autorisations sur votre système de fichiers.
J'ai eu cette erreur et je pense que c'est la même raison que la tienne
erreur lors du chargement des bibliothèques partagées: libnw.so: impossible d'ouvrir le fichier partagé fichier objet: Aucun fichier ou répertoire de ce type
Essaye ça. Correction des autorisations sur les fichiers:
cd /opt/Popcorn (or wherever it is)
chmod -R 555 * (755 if not ok)