Discussion :

[Yann__]

Bonjour tout le monde,

Voilà, j'ai un petit problème avec la fonction dlopen sous linux : je rencontre un message d'erreur à l'exécution de mon programme du type : libvehiculetest.so : undefined symbol : _ZN8VehiculeD2Ev, erreur retournée par dlerror().

libvehiculetest.so contient l'implémentation de ma classe VehiculeTest, fille de la classe abstraite Vehicule.
Le fichier .so a été compilé avec l'option -shared et l'exécutable avec l'option -rdynamic.

Est-ce que quelqu'un aurait une idée de ce qui peut clocher ? Si vous avez besoin de plus de précisions, n'hésitez pas à demander.

Merci d'avance.

[Yann__]

Bonjour à tous, je me permets de faire un petit up, je suis vraiment coincé là ^^ !

[eponyme]

Salut, je rencontrais le meme soucis, je l'ai résolu en compilant le .so avec le .o contenant la description de la classe, ce qui est moyen (et fait grossir le .so...).
Je suis toujours à la recherche d'une solution plus propre.

epo

[Médinoc]

Normalement, pour faire un plug-in en C++, toutes les méthodes de la classe Vehicule doivent être virtuelles pures, donc ton .so ne doit pas avoir besoin de définitions de fonctions de la classe...

[eponyme]

Toutes les méthodes de l'objet "embarqué" dans le .so doivent etre virtuelles pures ? et quand est il des méthode d'autres objet auquelles accèdent des fonction du .so ? Y a t'il des option de compilation spécifiques à avoir ?

epo

[valefor]

Quand je rencontre ce genre de problème je fait (de mémoire) :
- cppfilt _ZN8VehiculeD2Ev
- nm -C libvehiculetest.so
Et je cherche les symboles présents dans ma lib et celui demandé.

Sinon pour info :
http://tldp.org/HOWTO/Program-Librar....html#CPP-VS-C

[Yann__]

Merci à tous pour vos réponses, malheureusement aucune d'elles n'a fonctionné dans mon cas :

Eponyme, j'avais déjà essayé de compiler vehicule.o dans mon .so (ce qui est de toutes façons un peu trop sale), ça n'a pas fonctionné (toujours le même problème).

Médinoc, es-tu sûr de ce que tu nous dis là ? Je n'ai entendu ça nulle part ailleurs et je ne comprends pas vraiment pourquoi il devrait en être ainsi ? Et de toutes façons, le symbol qu'il ne trouve pas semble être le constructeur de la classe mère que je ne peux pas mettre virtuel pur (si ?).

Valefor, je ne connais pas l'utilitaire cppflit (et mon système non plus ^^), qu'est-il sensé faire ? J'avais déjà utilisé nm sur ma libvehiculetest.so, je n'ai pas compris la totalité de l'affichage mais _ZN8VehiculeD2Ev apparait bien...
edit : et j'avais aussi essayé de mettre la déclaration de ma classe Vehicule dans un extern "C"{} sans plus de succès...

Si vous avez d'autres idées...

[Médinoc]

Eh bien, typiquement, si on charge dynamiquement une bibliothèque C++, c'est généralement un plug-in, car je ne vois aucun intéret à charger dynamiquement une bibliothèque C++ sinon.

Alors, on se retrouve typiquement avec ceci:
Une interface/classe abstraite:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class IUneInterface
{
	virtual void Delete() = 0;
 
	virtual int FaireUntruc(int) = 0;
	virtual void BlaBla(IUneAutreInterface *) = 0;
};

Une bibliothèque qui l'implémente et contient une fonction qui la retourne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
class CUneImplementation : public IUneInterface
{
	void Delete();
 
	int FaireUnTruc(int);
	void BlaBla(IUneAutreInterface *);
};
 
void CUneImplementation::Delete()
{
	delete this;
}
 
void CUneImplementation::FaireUnTruc(int a)
{
	return a+42;
}
 
void BlaBla(IUneAutreInterface *pObj)
{
	pObj->Toto();
}
 
//Fonction exportée
extern "C" UNELIB_EXPORT IUneInterface * CreateUneInterfaceImpl(void)
{
	return new CUneImplementation();
}

Et l'utilisateur appelle cette lib pour utiliser l'objet:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
lib = dlopen("unelib.so");
createFunc = dlsym(lib, "CreateUneInterfaceImpl");
IUneInterface * iface = createFunc();
 
...
 
iface->Delete();
iface = 0;
dlclose(lib)

[Yann__]

Je suis tout à fait d'accord sur le fait que la classe soit abstraite y tout y tout, mais je ne vois pas pourquoi cette interface ne pourrait pas définir des comportements par défaut pour certaines méthodes.
Pour en revenir à mon cas, j'ai une classe mère Véhicule, abstraite, mais qui va implémenter certaines méthodes virtuelles comme avancer(), reculer(), etc. Ma classe VehiculeTest reprend le comportement par défaut de la classe mère, et à côté de ça j'ai une autre classe VehiculeTruc qui réimplémente toutes les méthodes.
Il n'est donc a priori pas nécessaire d'avoir toutes les méthodes de la mère virtuelles pures...

Il y a une chose que je ne comprend pas dans ton exemple : que signifie le UNELIB_EXPORT après ton extern "C" ?

[Médinoc]

Le problème, c'est que ces comportements par défaut, ton .so doit y avoir accès.
Donc, il faut inclure la définition de classe dans la DLL, car un .so ne peut pas charger dynamiquement des fonctions membres.

Pour le UNELIB_EXPORT, tu peux l'ignorer, j'avais oublié qu'il n'y avait pas de définition de ce type sous nux.

[screetch]

tu as en fait facons de faire marcher, je cite du moins portable au plus portable :

* linker ton executable avec une option specifique -Wl,-E ou -E (depends si tu utilises gcc pour liker ou ld). cela exporte tous les symboles du programme et les rendra disponibles pour dlopen.

* mettre ton code contenant la classe de base dans un .so, ta fonction main dans un programme qui est liée a ce .so

* mettre ton code contenant la classe de base dans un .so, ta fonction main dans un programme qui est liée a ce .so ET linker ton plugin avec le code de base (seule version qui marchera sous windows)

en gros, tu as :
* main.cc contient le code qui charge le plugin
* baseplug.cc contient le code de base du plugin
* plug.cc contient le plugin lui meme

premiere version :
g++ -Wl,-E main.cc baseplug.cc
g++ -shared plug.cc

deuxieme :
g++ -shared baseplug.cc -o libengine.so
g++ main.cc -lengine
g++ -shared plug.cc

troisieme :
g++ -shared baseplug.cc -o libengine.so
g++ main.cc -lengine
g++ -shared plug.cc -lengine

[eponyme]

Et les -rdynamic ca ne fait pas la meme chose (rendre dispo tous les symboles) ?

J'ai utilisé ca moi et ca semble fonctionner.

epo

[Yann__]

Ok, merci Medinoc, je comprends mieux maintenant. C'est bizarre que lorsque j'ai testé avec ma classe Vehicule virtuelle pure le problème soit resté... Je retenterai ça un peu plus tard. Au fait, comment ça se passera avec le constructeur de la mère ? Il est forcément appelé à la construction de la fille, non ?

screetch, merci pour tes différents exemples, mais il me faut impérativement un link dynamique (je ne sais pas quels seront les plugins présents lors de l'exécution) donc seule ta première solution m'intéresse. Et après l'avoir essayé, je me retrouve face au même message T_T.

Cela dit je suis d'accord avec eponyme, normalement l'option -rdynamic devrait faire la même chose...

[screetch]

les deux autres versions sont tout a fait dynamiques aussi. elles reviennent a compiler le code partagé dans une DLL, et la faire utiliser par l'executable principal. le plugin n'est pas changé!! essaye la solution numero 2 peut etre.

l'option de gcc -rdynamic est traduite par -Wl,-E sous linux, mais est plus portable, bonne remarque!

http://man.developpez.com/man3/dlopen.3.php
recherche -rdynamic

je viens de faire tous les essais sur un linux et ca a fonctionné dans les trois cas, d'ailleurs chaque executable généré, quelque soit la methode, est capable de charger tous les plugins, meme ceux qui ont été prévus pour une autre méthode (si je suis pas clair, disons que l'exe de la methode 1 avec le -rdynamic est capable de charger le plugin 3 linké avec le code dans un .so... si c'est toujours pas clair, dis toi juste que ca marche! )

[screetch]

si ca ne marche pas, tu es sur de ne pas avoir oublier de coder une implementation ?

[Yann__]

Effectivement, j'avais lu un peu trop vite je crois, mea culpa ! Je testerai tout ça demain, je vous tiens au courant.

Et non, toutes mes implémentations sont codées...

Merci pour ton aide, bonne soiré.

[Yann__]

Bonsoir tout le monde !

Bon, je me suis replongé dans mon petit problème et je l'ai réduit au plus simple afin de toruver d'où venait l'erreur... ben je n'ai pas trouvé !
Je vous mets ici mon code, si quelqu'un voit d'où peut venir le problème ce serait fantastique !

L'erreur retournée à l'exécution est :
/chemin/vers/libfille.so: undefined symbol: _ZN4MereD2Ev

Je compile avec gcc v4.1.3.

Je joins aussi le code en PJ avec l'exécutable et le .so (des fois que ça vienne de chez moi...)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 #ifndef __MERE_HPP
#define __MERE_HPP
 
/**
   \file   mere.hpp
**/
 
#include <string>
#include <map>
 
using namespace std;
 
class Mere
{
  public:
 
    virtual ~Mere() = 0;
    virtual void doAnything() = 0;
};
 
typedef Mere * (*fabriqueMere) ();
typedef void (*detruitMere) ( Mere * );
 
extern map<string, fabriqueMere> Fabrique_Mere;
extern map<string, detruitMere>  Detruit_Mere;
 
#endif // __MERE_HPP

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#ifndef __FILLE_HPP
#define __FILLE_HPP
 
/**
   \file fille.hpp
**/
 
#include "mere.hpp"
 
class Fille : public Mere
{
  public:
 
    virtual void doAnything();
};
 
#endif // __FILLE_HPP

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 /**
   \file fille.cpp
**/
 
#include <iostream>
#include "fille.hpp"
 
using namespace std;
 
void Fille::doAnything()
{
  cout << "Je fais un truc..." << endl;
}
 
 
extern "C"
{
  Mere * Create()
  { return new Fille(); }
 
  void Destroy( Mere * _m )
  { if ( _m ) delete _m; }
 
  class proxy
  {
    public:
      proxy()
      {
        Fabrique_Mere["fille"] = Create;
        Detruit_Mere["fille"]  = Destroy;
      }
  };
 
  proxy p;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 /**
   \file   main.cpp
**/
 
#include <iostream>
#include <string>
 
#include <dlfcn.h>     // chargement dynamique.
#include "mere.hpp"
 
using namespace std;
 
map<string, fabriqueMere> Fabrique_Mere;
map<string, detruitMere>  Detruit_Mere;
 
int main( int argc, char ** argv )
{
  void * desc = 0;
  desc = dlopen ( "/home/yann/Projet/testbench/libfille.so", RTLD_NOW );
  if ( !desc )
    cout << dlerror() << endl;
 
  return 0;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 CC = g++ 
BIN = test
CFLAGS = -Wall -ansi
LIBS   = -ldl
 
all: $(BIN) libfille.so
 
$(BIN): main.o
    $(CC) $(CFLAGS) -rdynamic -o $(BIN) main.o $(LIBS)
 
.cpp.o:
    $(CC) $(CFLAGS) -c $<
 
libfille.so: fille.o
    g++ -shared -Wl,-soname,libfille.so -o libfille.so fille.o

=================
Voui désolé

[screetch]

salut,

le probleme vient de ton destructeur virtuel pur. tu peux le laisser virtuel pur (cela empeche d'instancier la classe) mais tu dois fournir une implementation quand meme. le symbole _ZN4MereD2Ev fait reference au destructeur (du moins le D)
tout comme _ZN4MereC1Ev ferait reference a un constructeur.

[Yann__]

Salut screetch,

Il semblerait que tu aies raison en effet, bien que je ne comprenne pas pourquoi... Je ne savais même pas qu'on pouvait définir une méthode qui est virtuelle pure (en tous cas on ne peut pas le faire dans le .hpp) !

Enfin apparemment ce n'est pas le seul problème, je suis donc reparti du départ en ajoutant du code à mes classes petit à petit, et pour l'instant ça marche.

Merci à tous de m'avoir aidé, je repasserai peut-être si j'ai d'autres problème ^^.