web-dev-qa-db-fra.com

erreur lors du chargement des bibliothèques partagées: libboost_system.so.1.45.0: impossible d'ouvrir le fichier d'objet partagé: aucun fichier ou répertoire de ce type

Je construis un exécutable C++ sur Linux. L'exécutable est lié à certaines bibliothèques boost.

Ceci est la sortie lorsque j'essaie d'exécuter le binaire:

root@yourbox:~/work/dev/c++/projects/testfgci/dist/Debug/GNU-Linux-x86$ ./testfgci 
./testfgci: error while loading shared libraries: libboost_system.so.1.45.0: cannot open shared object file: No such file or directory

Je lance ensuite ldd sur le binaire pour vérifier les dépendances:

root@yourbox:~/work/dev/c++/projects/testfgci/dist/Debug/GNU-Linux-x86$ ldd testfgci 
    linux-gate.so.1 =>  (0x00380000)
    libboost_system.so.1.45.0 => not found
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00b50000)
    libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x005f6000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0099a000)
    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x001b3000)
    libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x00110000)
    /lib/ld-linux.so.2 (0x00ea2000)

Je ne sais pas pourquoi liboos_system.sl.1.45.0 SO est introuvable. Je l'ai construit avec succès un peu plus tôt aujourd'hui. Quelqu'un peut-il expliquer?

25
skyeagle

La bibliothèque est introuvable.

Les bibliothèques sont par défaut recherchées dans /lib, /usr/lib et les répertoires spécifiés par /etc/ld.so.conf.

Habituellement, les bibliothèques système (comme boost, si vous l'avez installé via votre gestionnaire de paquets) sont situées dans /usr/lib, mais ce n'est probablement pas votre cas.

Où se trouvent vos bibliothèques de boost sur votre système? Les avez-vous compilés par vous-même? Dans ce cas, vous devez indiquer à l'éditeur de liens dynamique de rechercher vos bibliothèques dans le répertoire où elles se trouvent en utilisant le LD_LIBRARY_PATH variable d'environnement:

LD_LIBRARY_PATH="your/boost/directory" ./testfgci

Je vous suggère d'installer des bibliothèques boost à l'aide de votre gestionnaire de paquets, de toute façon, cela vous simplifiera beaucoup la vie.

27
peoro

Je sais que c'est un ancien, mais vous pouvez exécuter ldconfig pour reconstruire votre cache ld. De cette façon, vous n'avez pas besoin de mettre à jour LD_LIBRARY_PATH.

20
ontek

Je voulais juste ajouter une note pour les utilisateurs d'Ubuntu (et Debian, je suppose): ces systèmes ont une "fonctionnalité" de sécurité qui efface LD_LIBRARY_PATH. Cela ne fonctionne pas:

Dans les deux cas /etc/environemnt ou ~/.profile ou ~/.bash_profile:

export LD_LIBRARY_PATH=/usr/local/boost_1_54_0/stage/lib:$LD_LIBRARY_PATH

Cela fonctionnera pour ~/.bashrc, mais le chemin sera défini uniquement pour ce shell interactif particulier. Cela signifie que si vous appelez make depuis par exemple emacs ou Eclipse, cela ne fonctionnera pas, sauf si vous avez lancé emacs depuis le shell et non depuis le lanceur.

C'est ce qui a fonctionné pour moi:

echo -e "\n/usr/local/boost_1_54_0/stage/lib" | Sudo tee -a /etc/ld.so.conf 
Sudo ldconfig
6
abo-abo