Problème dans lib*.so
Fermé
hassan-phea
-
Modifié par mamiemando le 20/05/2013 à 12:59
mamiemando Messages postés 33446 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 20 décembre 2024 - 25 mai 2013 à 13:59
mamiemando Messages postés 33446 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 20 décembre 2024 - 25 mai 2013 à 13:59
A voir également:
- Fichier .so
- Fichier rar - Guide
- Comment réduire la taille d'un fichier - Guide
- Comment ouvrir un fichier epub ? - Guide
- Fichier host - Guide
- Ouvrir fichier .bin - Guide
9 réponses
mamiemando
Messages postés
33446
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
20 décembre 2024
7 812
20 mai 2013 à 13:05
20 mai 2013 à 13:05
Non g++ se comporte de la même façon a priori que tu sois sous linux ou macos.
À mon avis c'est plutôt que le ".so" qui implémente tes objets FixTIDTopology ou toa n'est pas au même endroit et que les options -L ou -Wl,R que tu utilises pour linker n'ont pas de sens sous linux par exemple par ce que la librairie correspondante n'est pas au même endroit.
Si tu m'en dis un peu plus sur quelle(s) librairie(s) fournit ces objets et où elles sont positionnées sous linux, je pourrai te dire comment arranger tes options de compilation. Tu peux d'ores et déjà lire ceci :
https://forums.commentcamarche.net/forum/affich-27031310-compiler-avec-une-librairie-partagee
Bonne chance
À mon avis c'est plutôt que le ".so" qui implémente tes objets FixTIDTopology ou toa n'est pas au même endroit et que les options -L ou -Wl,R que tu utilises pour linker n'ont pas de sens sous linux par exemple par ce que la librairie correspondante n'est pas au même endroit.
Si tu m'en dis un peu plus sur quelle(s) librairie(s) fournit ces objets et où elles sont positionnées sous linux, je pourrai te dire comment arranger tes options de compilation. Tu peux d'ores et déjà lire ceci :
https://forums.commentcamarche.net/forum/affich-27031310-compiler-avec-une-librairie-partagee
Bonne chance
bonjour
j'ai essayé mais j'ai pas arrivé à obtenir un bon résultat ,j'ai l'honneur de resoudre ce problème sur ce forum ,puisque j'ai pas arrivé à obtenir une solution même que j'ai ouvert une dizaine de discussions sur des dizaine des forum
j'ai essayé mais j'ai pas arrivé à obtenir un bon résultat ,j'ai l'honneur de resoudre ce problème sur ce forum ,puisque j'ai pas arrivé à obtenir une solution même que j'ai ouvert une dizaine de discussions sur des dizaine des forum
morad@linux-nzlc:~/workdir/layout/analyze> make mainP=runAnalyze g++ -L/home/morad/workdir/library/tklibs/lib -L/home/morad/workdir/layout/lib -L/usr/lib -Xlinker -start-group -Xlinker -lGeomPropagators -Xlinker -lPatternPrimitives -Xlinker -lSurfaceGeometry -Xlinker -lBaseMagneticField -Xlinker -lUI -Xlinker -lGenUtil -Xlinker -lSiPixelDet -Xlinker -lSmearingClusterizers -Xlinker -lBasicDet -Xlinker -lTrackFitters -Xlinker -lTkFastSimHit -Xlinker -lCommonStripDet -Xlinker -lDetLayout -Xlinker -lTkLayout -Xlinker -lDetGeometry -Xlinker -lKalmanUpdators -Xlinker -lTkCommonDet -Xlinker -lPatternTools -Xlinker -lTrajectoryParametrization -Xlinker -lxmlgeom -Xlinker -ltrack -Xlinker -lcross -Xlinker -lMaterialEffects -Xlinker -lPropagators -Xlinker -ltracking -Xlinker -lgeom -Xlinker -lStatUtilities -Xlinker -lAnalyticalJacobians -Xlinker -lxmltkgeom -Xlinker -lutils -Xlinker -lopt -Xlinker -ldraw -Xlinker -lanalyze -Xlinker -lDetVolumeGeometry -Xlinker -lPatternTestTools -Xlinker -lRKPropagators -Xlinker -lBasicStripDet -Xlinker -lDetUtilities -Xlinker -lTkNavigation -Xlinker -lNumericalJacobians -Xlinker -ltkhist -Xlinker -end-group -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0 /usr/lib/preloadable_libintl.so -L/cern/ROOT/source/root/lib /usr/lib/libX11.so -L/cern/Minuit2/5.28.00/lib -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lfreetype -lz /usr/lib/libbz2.so.1.0.6 -pthread -Wl,-rpath,/cern/ROOT/source/root/lib -lm -ldl -L/cern/CLHEP/2.0.4.5/lib/ -lCLHEP-2.0.4.5 -O2 -lm /home/morad/workdir/layout/build/analyze/myAnalyze.o /home/morad/workdir/layout/build/analyze/runAnalyze.o -o runAnalyze.exe /usr/lib/gcc/i586-suse-linux/4.7/../../../../i586-suse-linux/bin/ld: warning: libMinuit2.so.0, needed by /home/morad/workdir/layout/lib/libxmlgeom.so, not found (try using -rpath or -rpath-link) /home/morad/workdir/library/tklibs/lib/libSmearingClusterizers.so: undefined reference to 'TrivialROUSetter::set(Module)' /home/morad/workdir/library/tklibs/lib/libTkLayout.so: undefined reference to 'FixTIDTopology::recreateTopologies()' /home/morad/workdir/library/tklibs/lib/libSmearingClusterizers.so: undefined reference to 'TkDetTypeName::shortName(DetType const&)' /home/morad/workdir/library/tklibs/lib/libTkLayout.so: undefined reference to 'DetUnitGluer::glue(__gnu_cxx::__normal_iterator<DetUnit**, std::vector<DetUnit*, std::allocator<DetUnit*> > >, __gnu_cxx::__normal_iterator<DetUnit**, std::vector<DetUnit*, std::allocator<DetUnit*> > >, __gnu_cxx::__normal_iterator<DetUnit**, std::vector<DetUnit*, std::allocator<DetUnit*> > >, __gnu_cxx::__normal_iterator<DetUnit**, std::vector<DetUnit*, std::allocator<DetUnit*> > >)' /home/morad/workdir/library/tklibs/lib/libTkFastSimHit.so: undefined reference to 'RawHepEventFactoryFromGun::RawHepEventFactoryFromGun()' /home/morad/workdir/library/tklibs/lib/libTkLayout.so: undefined reference to 'toa::operator()(int const&) const' /home/morad/workdir/library/tklibs/lib/libTkLayout.so: undefined reference to 'FixTIDTopology::FixTIDTopology()' /home/morad/workdir/library/tklibs/lib/libTkLayout.so: undefined reference to 'DetBlade::DetBlade(__gnu_cxx::__normal_iterator<Det* const*, std::vector<Det*, std::allocator<Det*> > >, __gnu_cxx::__normal_iterator<Det* const*, std::vector<Det*, std::allocator<Det*> > >)' /home/morad/workdir/library/tklibs/lib/libTkLayout.so: undefined reference to 'toa::~toa()' /home/morad/workdir/library/tklibs/lib/libTkLayout.so: undefined reference to 'FullTracker::instance()' collect2: erreur: ld a retourné 1 code d'état d'exécution make: *** [runAnalyze] Erreur 1 morad@linux-nzlc:~/workdir/layout/analyze>
mamiemando
Messages postés
33446
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
20 décembre 2024
7 812
22 mai 2013 à 01:08
22 mai 2013 à 01:08
Dans quel fichier(s)/librairie(s) sont définis FixTIDTopology, toa et FullTracker ?
bonjour
en fait les variables FixTidTopology,toa et FullTracker existent dans plusieurs fichiers *.cc et *.h .Dans mon code la commande ./myfind permet de trouver une variable dans un fichier .cc ou bien .h voici les fichiers contenant ces variables:
en fait les variables FixTidTopology,toa et FullTracker existent dans plusieurs fichiers *.cc et *.h .Dans mon code la commande ./myfind permet de trouver une variable dans un fichier .cc ou bien .h voici les fichiers contenant ces variables:
morad@linux-nzlc:~/workdir> ./myfind . *.h FixTIDTopology . *.h FixTIDTopology chercher FixTIDTopology dans les fichiers *.h se trouvant dans . ./library/tklibs/Tracker/TkLayout/interface/TopologyBuilderFromXML.h: void FixTIDTopologyAndPutInConstructMode(); ./library/tklibs/Tracker/TkLayout/interface/TopologyBuilder.h: void FixTIDTopologyAndPutInConstructMode(); ./library/tklibs/Tracker/TkLayout/interface/FixTIDTopology.h:#ifndef FixTIDTopology_H ./library/tklibs/Tracker/TkLayout/interface/FixTIDTopology.h:#define FixTIDTopology_H ./library/tklibs/Tracker/TkLayout/interface/FixTIDTopology.h:class FixTIDTopology { ./library/tklibs/Tracker/TkLayout/interface/FixTIDTopology.h: FixTIDTopology(); ./library/tklibs/Tracker/TkLayout/interface/PartialRedigitizeTID.h: * Patch for the bug explained in FixTIDTopology. To be called in the event loop, morad@linux-nzlc:~/workdir> ./myfind . *.cc FixTIDTopology . *.cc FixTIDTopology chercher FixTIDTopology dans les fichiers *.cc se trouvant dans . ./library/tklibs/Tracker/TkLayout/src/PartialRedigitizeTID.cc:#include "Tracker/TkLayout/interface/FixTIDTopology.h" ./library/tklibs/Tracker/TkLayout/src/PartialRedigitizeTID.cc: FixTIDTopology myFixTIDTopology; ./library/tklibs/Tracker/TkLayout/src/PartialRedigitizeTID.cc: myFixTIDTopology.recreateTopologies(); grep: ./layout/analyze/.#temp.cc: Aucun fichier ou dossier de ce type morad@linux-nzlc:~/workdir> ./myfind . *.h toa . *.h toa chercher toa dans les fichiers *.h se trouvant dans . ./library/tklibs/Utilities/GenUtil/interface/ioutils.h: Usage as in: string mystring; ... ; mystring += toa()(4.); ./library/tklibs/Utilities/GenUtil/interface/ioutils.h:class toa { ./library/tklibs/Utilities/GenUtil/interface/ioutils.h: inline toa(){} ./library/tklibs/Utilities/GenUtil/interface/ioutils.h: ~toa(); ./library/tklibs/Utilities/GenUtil/interface/ioutils.h: toa(const toa&){} ./library/tklibs/Utilities/GenUtil/interface/ioutils.h: void operator=(const toa&){} morad@linux-nzlc:~/workdir> ./myfind . *.cc toa . *.cc toa chercher toa dans les fichiers *.cc se trouvant dans . ./library/tklibs/Tracker/TkLayout/src/TkLayerName.cc: string num; num += toa()(counter); ./library/tklibs/CommonReco/DetVolumeGeometry/test/SingleVolumeTest.cc:extern int toascii (int __c) throw (); grep: ./layout/analyze/.#temp.cc: Aucun fichier ou dossier de ce type morad@linux-nzlc:~/workdir> ./myfind . *.h FullTracker . *.h FullTracker chercher FullTracker dans les fichiers *.h se trouvant dans . ./library/tklibs/Tracker/TkLayout/interface/FullTracker.h:#ifndef FullTracker_H ./library/tklibs/Tracker/TkLayout/interface/FullTracker.h:#define FullTracker_H ./library/tklibs/Tracker/TkLayout/interface/FullTracker.h:class FullTracker { morad@linux-nzlc:~/workdir> ./myfind . *.cc FullTracker . *.cc FullTracker chercher FullTracker dans les fichiers *.cc se trouvant dans . ./library/tklibs/Tracker/TkLayout/src/TkAllRingsDetLayerFactory.cc:#include "Tracker/TkLayout/interface/FullTracker.h" ./library/tklibs/Tracker/TkLayout/src/TkAllRingsDetLayerFactory.cc: DetUnitContainer dets = FullTracker::instance()->detsFromSim(); ./library/tklibs/Tracker/TkLayout/src/TkLayerName.cc:#include "Tracker/TkLayout/interface/FullTracker.h" ./library/tklibs/Tracker/TkLayout/src/TkLayerName.cc: LayerContainer barrelLayers = FullTracker::instance()->barrelLayers(); ./library/tklibs/Tracker/TkLayout/src/TkLayerName.cc: LayerContainer forwardLayers = FullTracker::instance()->forwardLayers(); ./library/tklibs/Tracker/TkLayout/src/NavigationPrinter.cc:#include "Tracker/TkLayout/interface/FullTracker.h" ./library/tklibs/Tracker/TkLayout/src/NavigationPrinter.cc: CmsTracker::LayerContainer layers = FullTracker::instance()->allLayers(); ./library/tklibs/Tracker/TkLayout/src/TkDetTypeByName.cc:#include "Tracker/TkLayout/interface/FullTracker.h" ./library/tklibs/Tracker/TkLayout/src/TkDetTypeByName.cc: const CmsTracker::DetContainer& units = FullTracker::instance()->dets(); ./library/tklibs/Tracker/TkLayout/src/TkDetLayerFactoryForNumbering.cc:#include "Tracker/TkLayout/interface/FullTracker.h" ./library/tklibs/Tracker/TkLayout/src/TkDetLayerFactoryForNumbering.cc: const DetUnitContainer& dets = FullTracker::instance()->dets(); ./library/tklibs/Tracker/TkLayout/src/TBNumberingFactory.cc:#include "Tracker/TkLayout/interface/FullTracker.h" ./library/tklibs/Tracker/TkLayout/src/TBNumberingFactory.cc: vector<DetUnit*> dets = FullTracker::instance()->dets(); ./library/tklibs/Tracker/TkLayout/src/LayerAccessor.cc:#include "Tracker/TkLayout/interface/FullTracker.h" ./library/tklibs/Tracker/TkLayout/src/LayerAccessor.cc: theTracker( *FullTracker::instance()) {} ./library/tklibs/Tracker/TkLayout/src/SimplePhiTkROUFactory.cc:#include "Tracker/TkLayout/interface/FullTracker.h" ./library/tklibs/Tracker/TkLayout/src/SimplePhiTkROUFactory.cc: DetContainer allDets = FullTracker::instance()->dets(); ./library/tklibs/Tracker/TkLayout/src/DetUnitROUDivider.cc:#include "Tracker/TkLayout/interface/FullTracker.h" ./library/tklibs/Tracker/TkLayout/src/DetUnitROUDivider.cc: CmsTracker::DetContainer theDet = FullTracker::instance()->detsFromSim(); ./library/tklibs/Tracker/TkLayout/src/DetUnitROUDivider.cc: FullTracker::instance()->dets(); grep: ./layout/analyze/.#temp.cc: Aucun fichier ou dossier de ce type morad@linux-nzlc:~/workdir>au moment de link les fichiers qui contiennent FullTracker et FixTIDTopology se rassemblent en d'autres fichiers pour crée libTkLayout.so
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
mamiemando
Messages postés
33446
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
20 décembre 2024
7 812
23 mai 2013 à 00:23
23 mai 2013 à 00:23
Bon prenons une au pif, mettons celle-là :
Ici on te dit que libTkLayout.so fait référence à une méthode recreateTopologies() d'un objet FixTIDTopology. Tu as d'ailleurs reporté dans ton précédent message à quel endroit le code de cette librairie fait référence à cette méthode :
Donc cette librairie, pour compiler correctement, doit être compilée avec le ".o" issu du ".cc" qui implémente cette librairie, ou linkée avec une librairie (.so ou .a) qui fournit cet objet et cette fonction.
D'où ma question : dans quels fichiers (.h et .cc) cette méthode est déclarée et implémentée ?
Que donne (en te plaçant dans le répertoire adéquat) :
Bonne chance
/home/morad/workdir/library/tklibs/lib/libTkLayout.so: undefined reference to 'FixTIDTopology::recreateTopologies()'
Ici on te dit que libTkLayout.so fait référence à une méthode recreateTopologies() d'un objet FixTIDTopology. Tu as d'ailleurs reporté dans ton précédent message à quel endroit le code de cette librairie fait référence à cette méthode :
./library/tklibs/Tracker/TkLayout/src/PartialRedigitizeTID.cc: myFixTIDTopology.recreateTopologies();
Donc cette librairie, pour compiler correctement, doit être compilée avec le ".o" issu du ".cc" qui implémente cette librairie, ou linkée avec une librairie (.so ou .a) qui fournit cet objet et cette fonction.
D'où ma question : dans quels fichiers (.h et .cc) cette méthode est déclarée et implémentée ?
Que donne (en te plaçant dans le répertoire adéquat) :
ldd libTkLayout.so
Bonne chance
merci beaucoup sur cette motivation
la commande ldd libTkLayout.so m'indique
la commande ldd libTkLayout.so m'indique
morad@linux-nzlc:~/workdir/library/tklibs/lib> ldd libSmearingClusterizers.so linux-gate.so.1 (0xb77b6000) libCLHEP-2.0.4.5.so => not found libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb76a2000) libm.so.6 => /lib/libm.so.6 (0xb7676000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7658000) libc.so.6 => /lib/libc.so.6 (0xb74b1000) /lib/ld-linux.so.2 (0xb77b7000) morad@linux-nzlc:~/workdir/library/tklibs/lib> ldd libTkLayout.so linux-gate.so.1 (0xb77b7000) libCLHEP-2.0.4.5.so => not found libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb767e000) libm.so.6 => /lib/libm.so.6 (0xb7652000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7634000) libc.so.6 => /lib/libc.so.6 (0xb748d000) /lib/ld-linux.so.2 (0xb77b8000) morad@linux-nzlc:~/workdir/library/tklibs/lib>
mamiemando
Messages postés
33446
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
20 décembre 2024
7 812
24 mai 2013 à 10:07
24 mai 2013 à 10:07
Tu n'as répondu qu'à la moitié de ma question, mais on voit déjà que le fait que libCLHEP ne soit pas trouvé est un mauvais départ pour que cette librairie ait une chance de marcher. De plus tu as lancé ldd pour une autre librairie que celle que je t'ai demandée...
hassan-phea
Messages postés
1
Date d'inscription
jeudi 23 mai 2013
Statut
Membre
Dernière intervention
24 mai 2013
24 mai 2013 à 12:57
24 mai 2013 à 12:57
au premier moment j'ai crée les qui vont stocker dans :
à mon avis lorsque je vais compiler pour génerer l'excutable par le makfile make mainP=runAnalyze à ce moment le compilateur va chercher de remplir ces cases ce n'arrive pas a le faire!!!!?. dans mon code j'ai un makfile pour génerer les librairies library et layout et un autre pour créer l'excutable
morad@linux-nzlc:~/workdir/library/tklibs/lib> ls libAnalyticalJacobians.so libDetGeometry.so libGeomPropagators.so libPatternTestTools.so libSmearingClusterizers.so libTkLayout.so libBaseMagneticField.so libDetLayout.so libKalmanUpdators.so libPatternTools.so libStatUtilities.so libTkNavigation.so libBasicDet.so libDetUtilities.so libMaterialEffects.so libPropagators.so libSurfaceGeometry.so libTrackFitters.so libBasicStripDet.so libDetVolumeGeometry.so libNumericalJacobians.so libRKPropagators.so libTkCommonDet.so libTrajectoryParametrization.so libCommonStripDet.so libGenUtil.so libPatternPrimitives.so libSiPixelDet.so libTkFastSimHit.so libUI.so morad@linux-nzlc:~/workdir/library/tklibs/lib>ces 30 librairies lorsque je fais ldd*.soune message d'erreur commun entre ces librairies: libCLHEP-2.0.4.5.so => not found dans la deuxième stade on va créer 11 librairies*.so et on va les stocker dans un fichier
morad@linux-nzlc:~/workdir/layout/lib> ls libanalyze.so libcross.so libdraw.so libgeom.so libopt.so libtkhist.so libtracking.so libtrack.so libutils.so libxmlgeom.so libxmltkgeom.so morad@linux-nzlc:~/workdir/layout/lib>mais après ldd *.so un message d'erreur commun entre ces 11 librairies
libGeomPropagators.so => not found
libPatternPrimitives.so => not found
libSurfaceGeometry.so => not found
libBaseMagneticField.so => not found
libUI.so => not found
libGenUtil.so => not found
libCLHEP-2.0.4.5.so => not found
libMinuit2.so.0 => not found
libCore.so => not found
libCint.so => not found
libRIO.so => not found
libNet.so => not found
libHist.so => not found
libGraf.so => not found
libGraf3d.so => not found
libGpad.so => not found
libTree.so => not found
libRint.so => not found
libPostscript.so => not found
libMatrix.so => not found
libPhysics.so => not found
libMathCore.so => not found
libThread.so => not found
ce qui est en gras fait partis sur ma machine au /cern/ROOT/source/root/libe tlibCLHEP-2.0.4.5.so se trouve /cern/CLHEP/clhep/lib/
à mon avis lorsque je vais compiler pour génerer l'excutable par le makfile make mainP=runAnalyze à ce moment le compilateur va chercher de remplir ces cases ce n'arrive pas a le faire!!!!?. dans mon code j'ai un makfile pour génerer les librairies library et layout et un autre pour créer l'excutable
mamiemando
Messages postés
33446
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
20 décembre 2024
7 812
25 mai 2013 à 13:59
25 mai 2013 à 13:59
Je pense que tu vois les choses de manière trop compliquées. Tu peux mettre autant de librairies que tu veux le principe est extrêmement simple.
A) Compilation
1) Pour appeler une fonction f dans un fichier toto.c, cette fonction f doit être au préalable déclarée à l'aide d'un prototype.
Comment : Généralement ce prototype est récupéré via un header. On peut aussi la faire d'autre manière (soit en écrivant directement le prototype en début de fichier, ce qui revient à reproduire ce qu'aurait fait l'inclusion du bon header. Mais cette approche revient à espérer que l'implémentation de cette fonction sera retrouver au linkage (voir (B)). Cette implémentation peut être retrouvée dans un module (fichier .o) ou dans une librairie (fichier .so ou .a).
Que se passe-t'il sinon : gcc refuse de compiler le toto.c et renvoie une erreur comme quoi la fonction n'a pas été déclarée.
2) Si toutes les déclarations ont été trouvées et que le fichier est syntaxiquement correct et cohérent, le fichier toto.o est produit.
B) Linkage
Le linkage revient à réunir un ensemble de fichiers binaires pour former un binaire cohérent. Un binaire peut-être :
1) un module (*.o) : c'est le résultat de la compilation d'un fichier .c
2) un exécutable (*)
3) un module de noyau (*.ko) : ça ne te concerne pas
4) une librairie ...
4)a) ... dynamique (*.so) (shared object). C'est ce que tu utilises, la librairie fait alors référence à d'autres librairies (voir ldd).
4)b) ... statique (*.a) (= stand alone), je vais passer dessus car ça ne te concerne pas ici.
Pour linker avec succès, il faut que toutes les fonctions impliquées (déclarées et utilisées) dans mon programme ait une implémentation, récupérée soit dans un .o, dans un .so ou dans .a.
Comment : il faut donner dans la ligne de compilation qui produit mon binaire tous les .so, .a et .o nécessaire à son linkage.
Que se passe-t'il sinon : supposons que le binaire que je veux compiler ait besoin d'une librairie dynamique (.so) disons libf.so, car j'ai besoin de la fonction f qu'elle fournit. Si libf n'est pas trouvée (absente du système, pas dans un répertoire "attendu"...) j'aurai une erreur "undefined reference ...". En effet mon binaire parle d'une fonction f qui a certes été déclarée (vu que j'ai passé l'étape de compilation avec succès), mais dont l'implémentation n'a jamais été trouvée.
C'est ce qui t'arrive.
Supposons maintenant que tu linkes ton binaire avec des librairies dynamiques (avec libf.so dans mon exemple). Dans ce cas, l'éditeur de lien (ld) mémorise dans ton binaire que celui-ci fait référence à libf.so. Ce sont ces liens que tu vois apparaître avec la commande ldd.
Si ldd indique des librairies "not found", cela signifie qu'elles étaient présentes au moment de la compilation de ce binaire (donc le linkage avait fonctionné à l'époque), mais depuis ces dernières ont disparues, et donc ton binaire est inutilisable en l'état.
C'est exactement ton cas pour tes 11 librairies qui font références notamment à libCore et autres. Cela signifie de plus qu'en l'état, tu ne peux sans doute pas recompiler ces 11 librairies.
C'est également ce qui t'arrive.
C) Exécution
Supposons que mon binaire était un exécutable.
Pour que celui-ci s'exécute avec succès, toutes les librairies dynamiques avec lesquelles il est linké doivent être retrouvées. Sinon le programme plante en indiquant quelle librairie est manquante.
==> Retour sur ton problème.
Pour que ton truc ait une chance de marcher il faut que toutes les libraires nécessaires au linkage soient présentes sur ton système. Ça ne ferait pas de mal d'ailleurs de recompiler celles qui sont issues de tes sources.
Il faut bien entendu compiler tes binaires dans l'ordre. Supposons que j'ai par exemple un exécutable toto qui dépend des librairies libb1 et libb2, et que libb1 dépend de liba1, liba2 et liba3, je dois compiler dans cet ordre :
- d'abord liba1, liba2 et liba3
- maintenant je peux compiler libb1
- je dois aussi compiler libb2
- une fois que libb1 et libb2 sont compilées, je peux compiler toto.
Le rôle d'un makefile est de t'éviter d'avoir à réfléchir sur cet ordre. Il suffit juste de dire que toto dépend de libb1.so, libb2.so, et de la même manière que libb1.so dépend de liba1.so liba2.so et liba3.so. Comme ça le jour où tu recompiles toto, en cascade make se débrouille pour voir qui a besoin d'être recompilé et dans quel ordre.
A) Compilation
1) Pour appeler une fonction f dans un fichier toto.c, cette fonction f doit être au préalable déclarée à l'aide d'un prototype.
Comment : Généralement ce prototype est récupéré via un header. On peut aussi la faire d'autre manière (soit en écrivant directement le prototype en début de fichier, ce qui revient à reproduire ce qu'aurait fait l'inclusion du bon header. Mais cette approche revient à espérer que l'implémentation de cette fonction sera retrouver au linkage (voir (B)). Cette implémentation peut être retrouvée dans un module (fichier .o) ou dans une librairie (fichier .so ou .a).
Que se passe-t'il sinon : gcc refuse de compiler le toto.c et renvoie une erreur comme quoi la fonction n'a pas été déclarée.
2) Si toutes les déclarations ont été trouvées et que le fichier est syntaxiquement correct et cohérent, le fichier toto.o est produit.
B) Linkage
Le linkage revient à réunir un ensemble de fichiers binaires pour former un binaire cohérent. Un binaire peut-être :
1) un module (*.o) : c'est le résultat de la compilation d'un fichier .c
2) un exécutable (*)
3) un module de noyau (*.ko) : ça ne te concerne pas
4) une librairie ...
4)a) ... dynamique (*.so) (shared object). C'est ce que tu utilises, la librairie fait alors référence à d'autres librairies (voir ldd).
4)b) ... statique (*.a) (= stand alone), je vais passer dessus car ça ne te concerne pas ici.
Pour linker avec succès, il faut que toutes les fonctions impliquées (déclarées et utilisées) dans mon programme ait une implémentation, récupérée soit dans un .o, dans un .so ou dans .a.
Comment : il faut donner dans la ligne de compilation qui produit mon binaire tous les .so, .a et .o nécessaire à son linkage.
Que se passe-t'il sinon : supposons que le binaire que je veux compiler ait besoin d'une librairie dynamique (.so) disons libf.so, car j'ai besoin de la fonction f qu'elle fournit. Si libf n'est pas trouvée (absente du système, pas dans un répertoire "attendu"...) j'aurai une erreur "undefined reference ...". En effet mon binaire parle d'une fonction f qui a certes été déclarée (vu que j'ai passé l'étape de compilation avec succès), mais dont l'implémentation n'a jamais été trouvée.
C'est ce qui t'arrive.
Supposons maintenant que tu linkes ton binaire avec des librairies dynamiques (avec libf.so dans mon exemple). Dans ce cas, l'éditeur de lien (ld) mémorise dans ton binaire que celui-ci fait référence à libf.so. Ce sont ces liens que tu vois apparaître avec la commande ldd.
Si ldd indique des librairies "not found", cela signifie qu'elles étaient présentes au moment de la compilation de ce binaire (donc le linkage avait fonctionné à l'époque), mais depuis ces dernières ont disparues, et donc ton binaire est inutilisable en l'état.
C'est exactement ton cas pour tes 11 librairies qui font références notamment à libCore et autres. Cela signifie de plus qu'en l'état, tu ne peux sans doute pas recompiler ces 11 librairies.
C'est également ce qui t'arrive.
C) Exécution
Supposons que mon binaire était un exécutable.
Pour que celui-ci s'exécute avec succès, toutes les librairies dynamiques avec lesquelles il est linké doivent être retrouvées. Sinon le programme plante en indiquant quelle librairie est manquante.
==> Retour sur ton problème.
Pour que ton truc ait une chance de marcher il faut que toutes les libraires nécessaires au linkage soient présentes sur ton système. Ça ne ferait pas de mal d'ailleurs de recompiler celles qui sont issues de tes sources.
Il faut bien entendu compiler tes binaires dans l'ordre. Supposons que j'ai par exemple un exécutable toto qui dépend des librairies libb1 et libb2, et que libb1 dépend de liba1, liba2 et liba3, je dois compiler dans cet ordre :
- d'abord liba1, liba2 et liba3
- maintenant je peux compiler libb1
- je dois aussi compiler libb2
- une fois que libb1 et libb2 sont compilées, je peux compiler toto.
Le rôle d'un makefile est de t'éviter d'avoir à réfléchir sur cet ordre. Il suffit juste de dire que toto dépend de libb1.so, libb2.so, et de la même manière que libb1.so dépend de liba1.so liba2.so et liba3.so. Comme ça le jour où tu recompiles toto, en cascade make se débrouille pour voir qui a besoin d'être recompilé et dans quel ordre.