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

StackOverflow https://stackoverflow.com/questions/480764

Question

Le programme fait partie de la suite de tests Xenomai, compilée de manière différente à partir de Linux PC dans la chaîne d’outils Linux + Xenomai.

# 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                                 

Modifier: OK, je n'ai pas remarqué que le fichier .1, à la fin, faisait partie du nom du fichier. Qu'est-ce que cela signifie quand même?

Était-ce utile?

La solution

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 le & "-Dev &" ; version de ce paquet.

Eh bien, il ne ment pas - il n'y a pas 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 votre bibliothèque, ou d'installer tout ce qui fournit libpthread_rt.so.

Généralement, les numéros après le .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 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 ayant besoin de cette version peut utilisez le fichier libfoo.so.1.0. Un code qui repose 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 orip a été souligné dans les commentaires, cela est expliqué à http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html .

Dans votre cas, vous pourriez vous en tirer avec un lien symbolique <=> vers <=>. Rien ne garantit que votre code ne sera pas enfreint et que vos dîners télévisés ne mangent pas.

Autres conseils

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

Pour ce faire, nous devrons faire ces étapes faciles:

(1) Recherchez l'emplacement de la bibliothèque si vous ne la connaissez pas.

sudo find / -name the_name_of_the_file.so

(2) Vérifiez 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 où se trouve le path.so.something. Donc, si /my_library/path.so.something est dans <=>, il devrait être:

$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_library/
$ export LD_LIBRARY_PATH
$ ./my_app

source: http://www.gnu.org/ logiciel / 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 exécuter ldconfig .

sudo ldconfig
  

ldconfig crée les liens nécessaires et met en cache les plus récents   bibliothèques partagées trouvées dans les répertoires spécifiés dans la commande   line, dans le fichier /etc/ld.so.conf et dans les répertoires de confiance   (/ lib et / usr / lib).

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

Paquet de développement ou version incorrecte

Si cela ne fonctionne pas, je vérifierais également la suggestion de Paul et rechercherai un " -dev " version 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 dans différentes versions simultanément, par exemple, Python.

Emplacement de la bibliothèque

Si vous êtes certain que le bon package est installé et que ldconfig ne l’a pas trouvé, il se peut qu’il se trouve simplement 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 ajouter le répertoire sur sa propre ligne dans ldconfig, ajouter le chemin d'accès de la bibliothèque à libraryname ou déplacer la bibliothèque dans ~/.bashrc. Puis exécutez <=>.

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

sudo find / -iname *libraryname*.so*

(Remplacez <=> par le nom de votre bibliothèque)

Si vous choisissez la route <=>, vous voudrez l'inscrire dans votre fichier <=> afin qu'il s'exécute chaque fois que vous vous connectez:

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

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

sudo ldconfig -v

J'espère que ça aide.

Vous devez vous assurer de spécifier 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 une bibliothèque. dans / 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 en rien la motivation qui la sous-tend: - (

Pour cela, consultez le Guide de Sun Linker and Libraries .

De plus, notez que " versioning externe " est en grande partie obsolète sur Linux, car la gestion des versions de symboles (une 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 depuis 10 ans.

Essayez d'ajouter LD_LIBRARY_PATH, qui indique les chemins de recherche, à votre ~/.bashrc fichier

.
LD_LIBRARY_PATH=path_to_your_library

Cela fonctionne!

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

Ensuite, ls -l /lib devrait maintenant afficher le lien symbolique et son orientation.

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, c’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 affiche vos fichiers de bibliothèque, vous pouvez continuer.

J'ai rencontré cette erreur lors de l'exécution de mon application avec Eclipse CDT sous Linux x86.
Pour résoudre ce problème:

  1. Dans Eclipse:
      

    Exécuter en tant que - > Exécuter les configurations - & Gt; Environnement

  2. Définissez le chemin

    LD_LIBRARY_PATH=/my_lib_directory_path
    

essayez d'installer sudo lib32z1

  

sudo apt-get install lib32z1

Tout ce que je devais faire était de courir

sudo apt-get install libfontconfig1

J'étais dans le dossier situé à /usr/lib/x86_64-linux-gnu et cela fonctionnait parfaitement.

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.

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:

  1. Exécuter locate libpthread_rt.so.1 listera le chemin de tous les fichiers portant ce nom. Supposons qu'un chemin est /home/user/loc.
  2. 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.
  3. Exécuter vi .bash_profile et à la fin du paramètre LD_LIBRARY_PATH, juste avant ., ajoutez la ligne /lib://home/usr/loc:.. Enregistrez le fichier.
  4. Fermez le terminal et redémarrez l'application. Il devrait fonctionner.

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

Essayez ceci. Correction des autorisations sur les fichiers:

cd /opt/Popcorn (or wherever it is) 
chmod -R 555 * (755 if not ok) 
chown -R root:root *

& # 8220; sudo su & # 8221; pour obtenir des autorisations sur votre système de fichiers.

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 les fichiers partagés   Fichier objet: Aucun fichier ou répertoire de ce type

Essayez ceci. Correction des autorisations sur les fichiers:

cd /opt/Popcorn (or wherever it is) 
chmod -R 555 * (755 if not ok) 

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 paquet libwbclient à fedora:

dnf reinstall libwbclient
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top