Discussion :

[Astropof]

Bonjour à tous.
Quelqu'un connaît gcc ?
J'ai compilé un petit .so :

# options pour les dependences:
-MM -P -w

# compilation j'ai bien utilisé fPIC
-fPIC

# et j'ai assemblé ma librairie
-shared -Wl,-rpath,bon_chemin -omylib -ldl mylib

Je rencontre ce message, venant de gcc, quand je veux compiler mon programme final:

>g++ -g -fno-weak -Wall -DDEBUG -otestprog MainLoop.o -L$(LIBS) -lmylib

Linkage : MainLoop.o
./libmylib.so: undefined reference to `LAG::Node::Node()'
./libmylib.so: undefined reference to `LAG::Node::~Node()'
./libmylib.so: undefined reference to `typeinfo for LAG::Node'
collect2: ld returned 1 exit status
make: *** [testprog] Erreur 1

La classe qui semble poser problème à ld est abstraite (LAG::Node). C'est un fichier .h qui ne contient que des déclarations. Mais les autres classes l'utilisent. Et la compilation de la librairie .so se passe sans problème. Les fichiers de dépendances l'incluent comme il faut.

Est-ce que les références sur cette classe sont absentes de la table de PIC et pourquoi ?

[Matthieu Brucher]

Il n'arrive pas à trouver le constructeur ni le destructeur de ta classe. Tu lies bien avec la DLL ?

[Jean-Marc.Bourguet]

La classe qui semble poser problème à ld est abstraite (LAG::Node). C'est un fichier .h qui ne contient que des déclarations.

Tu peux montrer ce .h? Ma boule de cristal me dit:
- que tu as déclaré qu'il y avait un constructeur LAG::Node::Node() mais que tu n'en as pas donné la définition,
- que tu as déclaré qu'il y avait un destructeur LAG::Node::~Node() mais que tu n'en as pas donné la définition,
- que tu as déclaré qu'il y avait un membre virtuel, mais que tu n'en as pas donné la définition. Au sujet de ce dernier, même si tu as déclaré le destructeur virtuel pur, tu dois en donner une définition.

[Astropof]

Oui, le problème venait en effet du code et pas de gcc (qui marche très bien).
Sans doute le constructeur de ma classe de base qui devait manquer, tout simplement.
Je l'ai transformée en classe concrète, avec des redéfinitions en aval :

#ifndef _NODE_H_
#define _NODE_H_

#include "Body.h"

namespace LAG
{
class Node
{
public:
Node();
Node(const Node&);
virtual ~Node();
bool AddIndexAttr();
bool AddAttr(const std::string&, const std::string&);
uint16_t GetIndex();
bool SetIndex(uint16_t);
const std::string* GetName();
bool SetBody(Body*);
bool SetParent(Node*);
bool SetFirstChild(Node*);
bool SetNext(Node*);
bool SetPrev(Node*);
relpos_t Compare(Node*);
void operator--(int);
void operator++(int);
template <class T> T* AddChild(T*);
template <class T> T* AddSibling(T*);
bool RemoveFirstByName(const char *);
std::list<Node*>* FindByName(const char *, std::list<Node*>*);
std::list<Node*>* FindWhereAttrEquals(attribute*, std::list<Node*>*);
//std::list<Node*>* FindWhereAttrDefined(attribute); /* TODO */
//std::list<Node*>* FindWhereBodyContains(std::string); /* TODO */
void Show(std::ostream&);
void ChainedShow(std::ostream&);
void ChainedCascadeShow(std::ostream&);

protected:
Body* body;
uint16_t index;
const std::string* name;
str_pairs_list attrList;
Node* firstChild;
Node* parent;
Node* prevSib;
Node* nextSib;
};
};

#endif /*_NODE_H_*/

/*
* A Declaration redefines some aspects :
* - can't have body,
* - nor children,
* - nor parents,
* - renders differently
*
*/

#ifndef _DECLARATION_H_
#define _DECLARATION_H_

#include "Element.h"
#include "Body.h"
#include "Node.h"

namespace LAG
{
class Declaration : public Node
{
public:
Declaration(const std::string&);
Declaration(const std::string&, uint16_t);
~Declaration();
bool SetBody(Body*); // throws
bool SetParent(Node*); // throws
bool SetFirstChild(Node*); // throws
template <class T> T* AddChild(T*);
void Show(std::ostream&);
void ChainedShow(std::ostream&);
void ChainedCascadeShow(std::ostream&);
};
};

#endif /*_DECLARATION_H_*/

Maintenant j'ai un autre problème, puisque mon programme de test se met en boucle qqpart dans la STL, comme le montre cet extrait de gdb :

(gdb) up 1000000000000
#0 0x0000002a95679d2d in operator!=<const std::string*, std::vector<std::string, std::allocator<std::string> > > (__lhs=@0x7fbffff110, __rhs=@0x7fbffff100)
at stl_iterator.h:700
700 { return __lhs.base() != __rhs.base(); }
(gdb) down 500000000000
#0 0x0000002a95679d2d in operator!=<const std::string*, std::vector<std::string, std::allocator<std::string> > > (__lhs=@0x7fbffff110, __rhs=@0x7fbffff100)
at stl_iterator.h:700
700 { return __lhs.base() != __rhs.base(); }
(gdb) down 1
#0 0x0000002a95679d2d in operator!=<const std::string*, std::vector<std::string, std::allocator<std::string> > > (__lhs=@0x7fbffff110, __rhs=@0x7fbffff100)
at stl_iterator.h:700
700 { return __lhs.base() != __rhs.base(); }

Là, ça échappe 1° à mes compétences (qui ne demandent qu'à être étendues) 2° à mes ressources de temps (celle-ci par contre...)

[Matthieu Brucher]

C'est dans ton code, quelque part, mais avec ce que tu nous a donné, impossible de savoir où.