Erreur Linux lors du chargement des bibliothèques partagées: impossible d'ouvrir le fichier d'objet partagé: aucun fichier ou répertoire de ce type


356

Le programme fait partie de la suite de tests Xenomai, compilée de manière croisée à partir du 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 .1 à la fin faisait partie du nom de fichier. Qu'est-ce que cela veut dire de toute façon?


277
Cela peut se produire si vous avez récemment installé une bibliothèque partagée et n'avez pas exécuté ldconfig (8) par la suite. Faites 'ldconfig', il n'y a aucun mal à cela.
AbiusX

25
+1 au commentaire @AbiusX - exécution de sudo ldconfig (en supposant que les bibliothèques sont en fait là où elles devraient être [/ usr / bin / lib /, / usr / bin / include /, / usr / local / lib / et / usr / local / include / AFAIK], veuillez me corriger si je me trompe) peut résoudre ce problème. À votre santé!
AeroCross

Notez que cette erreur peut également survenir si les autorisations sur votre fichier lib ont été modifiées d'une manière ou d'une autre. Changer les autorisations à 644 l'a résolu pour moi.
Geoffrey H

Réponses:


140

Mise à jour
Bien que ce que j'écris ci-dessous soit vrai comme réponse générale sur les bibliothèques partagées, je pense que la cause la plus fréquente de ce type de message est parce que vous avez installé un package, mais pas installé la version "-dev" de ce package.


Eh bien, ce n'est pas mentir - il n'y libpthread_rt.so.1en a pas dans cette liste. Vous devrez probablement le reconfigurer et le reconstruire de sorte qu'il dépende de la bibliothèque que vous avez, ou installer tout ce qui fournit libpthread_rt.so.1.

Généralement, les numéros après le .so sont des numéros de version, et vous constaterez souvent qu'ils sont des liens symboliques entre eux, donc si vous avez la version 1.1 de libfoo.so, vous aurez un vrai fichier 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 qui nécessite cette version exacte peut utilisez le fichier libfoo.so.1.0. Le code qui repose uniquement sur l'API de la version 1, mais ne se soucie pas si c'est 1.0 ou 1.1 spécifiera libfoo.so.1. Comme orip l'a souligné dans les commentaires, cela est bien expliqué sur http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html .

Dans votre cas, vous pourriez vous en sortir avec un lien symbolique libpthread_rt.so.1vers libpthread_rt.so. Cependant, rien ne garantit qu'il ne cassera pas votre code et ne mangera pas vos dîners télévisés.


5
... oh mon dieu, le .1 fait partie du nom de fichier. Une idée de ce que cela signifie?
zaratustra le

orip mérite un +1 pour ce lien. Si cela ne vous dérange pas, @orip, je voudrais mettre votre lien dans la réponse?
Paul Tomblin

@PaulTomblin, je reçois une erreur similaire lors de la réparation de grub. Pouvez-vous m'aider à ce sujet? Cette question -> askubuntu.com/questions/123275/cant-repair-grub/…
Eray

@TomNysetvold et Paul, oui - c'est le même document.
orip

Je suis tombé sur beaucoup de mauvaises informations et de solutions de détournement dans ma recherche de cette réponse. Quelque chose en moi m'a dit de continuer à chercher jusqu'à ce que je trouve une solution à commande unique.
c ..

327

Votre bibliothèque est une bibliothèque dynamique. Vous devez indiquer au système d'exploitation où il peut le localiser lors de l'exécution.

Pour ce faire, nous devrons suivre ces étapes simples:

(1) Trouvez où la bibliothèque est placée si vous ne la 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 du désir, l'exportons et essayons l'application.

Notez que le chemin doit être le répertoire où se path.so.somethingtrouve le. Donc, si path.so.somethingc'est /my_library/path.so.somethingdedans, ça 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


3
La réponse mentionnée ci-dessus était très claire, merci tout d'abord. J'ai essayé de le faire dans mon chemin de projet Eclipse CDT (Lubuntu). / Debug $ echo $ LD_LIBRARY_PATH /home/akhil/HDE/x86.linux/lib:/home/akhil/HDE/x86.linux/lib .. "/home/akhil/HDE/x86.linux/lib" c'est là que mes bibliothèques sont en fait disponibles même, mais je reçois toujours la même erreur. Aucune suggestion!
nahasapeemapetilon

12
Essayez une commande "ldconfig" après avoir exporté votre bibliothèque. Vous devrez peut-être exécuter cette commande en tant que "sudo".
XOR

5
Toutes les commandes de l'étape (1) peuvent être findfind / -name the_name_of_the_file.so
exécutées

3
Je crois que LD_LIBRARY_PATHdevrait pointer vers le répertoire contenant path.so.something, pas vers path.so.somethinglui-même.
gerrit

2
Suivre vos commandes étape par étape a résolu mon problème! Merci beaucoup!
Fisher Coder

156

Voici quelques solutions que vous pouvez essayer:

ldconfig

Comme l'a souligné AbiusX: Si vous venez d'installer la bibliothèque, vous devrez peut-être simplement exécuter ldconfig .

sudo ldconfig

ldconfig crée les liens et le cache nécessaires vers les bibliothèques partagées les plus récentes trouvées dans les répertoires spécifiés sur la ligne de commande, dans le fichier /etc/ld.so.conf et dans les répertoires approuvés (/ lib et / usr / lib).

Habituellement, votre gestionnaire de paquets s'en chargera lorsque vous installerez une nouvelle bibliothèque, mais pas toujours, et cela ne fera pas de mal d'exécuter ldconfig même si ce n'est pas votre problème.

Package de développement ou mauvaise version

Si cela ne fonctionne pas, je vérifierais également la suggestion de Paul et rechercherais 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 la 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 sûr que le bon package 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 regarde dans /lib, /usr/libet répertoires listés dans /etc/ld.so.confet $LD_LIBRARY_PATH. Si votre bibliothèque est ailleurs, vous pouvez soit ajouter le répertoire sur sa propre ligne /etc/ld.so.conf, ajouter le chemin d'accès à $LD_LIBRARY_PATHla bibliothèque, soit déplacer la bibliothèque dans /usr/lib. Ensuite, courez ldconfig.

Pour savoir où se trouve la bibliothèque, essayez ceci:

sudo find / -iname *libraryname*.so*

(Remplacez librarynamepar le nom de votre bibliothèque)

Si vous suivez la $LD_LIBRARY_PATHroute, vous voudrez mettre cela dans votre ~/.bashrcfichier pour qu'il s'exécute à chaque fois que vous vous connectez:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/library

3
Par défaut, / lib et / usr / lib mais pas / usr / local / lib? Cela m'a bouleversé plusieurs fois au cours de ma carrière et a fait perdre des heures.
DarenW

@DarenW For me fonctionne avec / usr / local / lib. Ubuntu 14.04 LTS.
gon1332

L'ajout .confde mes propres fichiers avec les chemins de bibliothèque non standard dont j'ai besoin /etc/ld.so.conf.d(indiqué par /etc/ld.so.conf) a fait l'affaire.
CivFan

4
+1 pour avoir besoin d'exécuter ldconfig. Je n'utilisais pas de gestionnaire de paquets. J'ai dû compiler à partir de la source, donc c'était nécessaire.
Jeff

7
c'est la vraie réponse
Scott Stensland

53

J'ai eu une erreur similaire, je pouvais la résoudre en donnant,

sudo ldconfig -v

J'espère que cela t'aides.


37
Hiya, cela pourrait bien résoudre le problème ... mais ce serait bien si vous pouviez modifier votre réponse et fournir une petite explication sur comment et pourquoi cela fonctionne :) N'oubliez pas - il y a des tas de débutants sur le débordement de la pile, et ils pourraient apprendre une chose ou deux de votre expertise - ce qui est évident pour vous pourrait ne pas l'être pour eux.
Taryn East, le

Il ne pourra pas l'expliquer. Il a juste copié sa réponse.
Jhourlad Estrella

réponse en double ... voir la même réponse ci-dessus conçue la veille
Scott Stensland

25

Vous devez vous assurer que vous spécifiez le chemin de la bibliothèque lors de la liaison lorsque vous compilez 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èque dans / usr / local / lib au moment de l'exécution avant d'essayer d'utiliser celle dans / usr / lib /

J'espère que cela vous aidera.


3
C'est l'option que je cherchais. Ce serait peut-être mieux -Wl,-rpath DIR.
jrw32982 prend en charge Monica

1
génial! J'ai rencontré ce problème lorsque mon programme a été compilé avec succès avec cmake mais n'a pas pu démarrer en raison d'une erreur. Cette réponse a résolu mon problème
Ivan Talalaev

15

Essayez d'ajouter LD_LIBRARY_PATH, qui indique des chemins de recherche, à votre ~/.bashrcfichier

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path_to_your_library

Ça marche!


13

La page de référence linux.org explique la mécanique, mais n'explique aucune des motivations derrière elle :-(

Pour cela, consultez Sun Linker and Libraries Guide

De plus, notez que le «versionnage externe» est largement obsolète sous Linux, car le versionnage de symboles (une extension GNU) vous permet d'avoir plusieurs versions incompatibles de la même fonction pour être présentes dans une seule bibliothèque. Cette extension a permis à glibc d'avoir la même version externe: libc.so.6depuis 10 ans.


7
cd /home/<user_name>/
sudo vi .bash_profile

ajoutez ces lignes à la fin

LD_LIBRARY_PATH=/usr/local/lib:<any other paths you want>
export LD_LIBRARY_PATH

5

J'ai eu une erreur similaire et elle n'a pas été corrigée en donnant LD_LIBRARY_PATH dans ~ / .bashrc. Ce qui a résolu mon problème, c'est en ajoutant un fichier .conf et en le chargeant. 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 enregistrez (par exemple: / usr / local / lib). Vous devez exécuter la commande suivante pour activer le chemin:

ldconfig

Vérifiez votre nouveau chemin de bibliothèque:

ldconfig -v | less

Si cela montre vos fichiers de bibliothèque, alors vous êtes prêt à partir.


4

Une autre solution possible selon 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

Ensuite, ls -l /libdevrait maintenant montrer le lien symbolique et ce qu'il pointe.


4

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:

  1. Dans Eclipse:

    Exécuter en tant que -> Exécuter les configurations -> Environnement

  2. Définissez le chemin

    LD_LIBRARY_PATH=/my_lib_directory_path
    

2

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-gnuet cela fonctionnait parfaitement.


2

Si vous exécutez votre application sur 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.


1

essayez d'installer sudo lib32z1

sudo apt-get install lib32z1


1

L'erreur se produit car le système ne peut pas se référer au fichier de bibliothèque mentionné. Suivez les étapes suivantes:

  1. Running locate libpthread_rt.so.1affichera le chemin de tous les fichiers portant ce nom. Supposons qu'un chemin soit /home/user/loc.
  2. Copiez le chemin et exécutez cd home/USERNAME. Remplacez USERNAME par le nom de l'utilisateur actif actuel avec lequel vous souhaitez exécuter le fichier.
  3. Exécutez vi .bash_profileet à la fin du LD_LIBRARY_PATHparamètre, juste avant ., ajoutez la ligne/lib://home/usr/loc:. . Enregistrez le fichier.
  4. Fermez le terminal et redémarrez l'application. Il devrait fonctionner.

0

J'ai cette erreur et je pense que c'est la même raison que la vôtre

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.


0

J'ai cette erreur et je pense que c'est la même raison que la vôtre

erreur lors du chargement des bibliothèques partagées: libnw.so: impossible d'ouvrir le fichier d'objet partagé: 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) 

0

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 des questions précédentes peuvent fonctionner. Mais je pense que c'est un moyen facile de le réparer. Essayez de réinstaller le package libwbclient dans fedora:

dnf reinstall libwbclient

0

J'utilise Ubuntu 18.04

L'installation du package "-dev" correspondant a fonctionné pour moi,

sudo apt install libgconf2-dev

J'obtenais l'erreur ci-dessous jusqu'à ce que j'installe le package ci-dessus,

turtl: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.