xerces-c 2.8: erreur lors du chargement des bibliothèques partagées

Je suis en train de compiler un programme s'exécutant sur un serveur HP UX sur un Red Hat Linux.xerces-c 2.8: erreur lors du chargement des bibliothèques partagées

Il utilise la bibliothèque xerces-c pour analyser les fichiers xml. La compilation est ok, mais lorsque je tente de l'exécuter, je reçois le message suivant

./a.out: Erreur lors du chargement partagé bibliothèques: libxerces-c.so.28: ne peut pas ouvrir le fichier objet partagé : Aucun fichier ou répertoire

moi avons écrit un programme très simple pour essayer de comprendre ce qui se passe:

#include <xercesc/util/PlatformUtils.hpp> 
#include <xercesc/util/TransService.hpp> 
#include <xercesc/parsers/SAXParser.hpp> 
#include <xercesc/util/OutOfMemoryException.hpp> 



int main(int argc, char* argv[]) 
{ 
     return 0; 
}

et compilé comme ceci:

g ++ test.cpp -L./xml/xerces-c_2_8_0/lib -lxerces-c -I./xml/xerces-c_2_8_0/include

Étonnamment, le fichier est en fait là:

lib]$ ls 
libxerces-c.a libxerces-c.so.28 libxerces-depdom.a libxerces-depdom.so.28 
libxerces-c.so libxerces-c.so.28.0 libxerces-depdom.so libxerces-depdom.so.28.0

Des pensées? Je sens qu'il me manque quelque chose, mais je ne sais pas quoi.

Merci d'avance.

Source

2009-11-12 Tom

course ldd a.out et voir si l'éditeur de liens peut résoudre le droit .so fichier

exportation LD_LIBRARY_PATH pour inclure le dossier en cours (de la même manière que la variable PATH) et vérifiez ldd nouveau

Source

2009-11-12 14:29:58 catwalk

merci! ldd ne peux pas trouver libxerces-c.so.28 !! – Tom

la bonne façon de faire ce que vous voulez est la suivante:

g++ test.cpp -Xlinker -R ./xml/xerces-c_2_8_0/lib -lxerces-c -I./xml/xerces-c_2_8_0/include

g++ test.cpp -Wl,-rpath ./xml/xerces-c_2_8_0/lib -lxerces-c -I./xml/xerces-c_2_8_0/include

Options Xlinker ou Wl vous permettent d'utiliser des options de liaison spécifiques, vous ne avez pas besoin de modifiy LD_LIBRARY_PATH

Source

2009-11-12 15:39:51

Je n'aime pas mettre à jour le chemin de recherche d'exécution d'un exécutable, car cela va à l'encontre de LD_LIBRARY_PATH. "Le principal inconvénient de l'utilisation de RPATH réside dans le fait qu'il remplace les paramètres LD_LIBRARY_PATH, ce qui rend l'exécution d'un fichier binaire précompilé hors du répertoire de base d'un utilisateur ou d'un autre emplacement par défaut difficile ou impossible. rend également difficile, voire impossible, la mise à niveau des bibliothèques sans forcer la réinstallation de tous les logiciels dépendant (même des anciennes versions) des bibliothèques. " –

donc selon vous, chaque fois que j'installe une nouvelle bibliothèque, je dois l'ajouter au chemin? Alors ajoutons boost et tous les autres partagés foutues bibliothèques ... –

Non. Chaque fois que vous créez un nouveau répertoire de bibliothèque, vous devez ajouter le nouveau répertoire à LD_LIBRARY_PATH. Mais vous ne devriez pas avoir besoin de créer de nouveaux répertoires de bibliothèques si souvent, puisque vous pouvez consolider les bibliothèques dans un seul répertoire standard (/ usr/local/lib ou quoi que ce soit). –

Vous devez indiquer la bibliothèque c d'exécution où trouver les différents symboles qui ne coûtent pas compilés statiquement dans votre code et ne coûtent pas dans les emplacements usualy/lib et/usr/lib.

Pour ce faire, ajoutez le chemin d'accès à votre bibliothèque partagée à LD_LIBRARY_PATH. Dans ce cas, ce sera ce que vous avez mis pour l'argument -L du compilateur.

Source

2009-11-13 08:39:52 IanNorton

xerces-c 2.8: erreur lors du chargement des bibliothèques partagées

Répondre

Questions connexes