utilisation d'un objet dans une bibliotheque dynamique

Version imprimable

14/02/2007, 13h30
eponyme

utilisation d'un objet dans une bibliotheque dynamique

Bonjour.
J'ai un projet dans lequel j'utilise des librairies dynamiques.(pour un systeme de plugin).
Mon souci viens du codage d'une librairie. Dans cette librairie, je déclare une classe, ses méthodes etc ... pas de soucis.
J'ai ensuite une fonction "a part" dans la librairie, qui prend un argument un pointeur sur l'objet défini dans la librairie, et une autre pointeur, sur un autre objet.

Avec chacun de ces pointeurs, j'utilise des méthodes des objets.
Ca compile parfaitement.
En revanche a l'exécution, j'ai une erreur "unknwown symbol" lors de l'ouverture de la librairie.(je n'ai pas d'erreur si je ne fais qu'utiliser un attribut de l'objet).

Si je commente la ligne ou j'utilise la méthode de l'objet "a part", je n'ai plus d'erreur d'exécution (en laissant la ligne ou j'utilise la méthode de l'objet défini dans la librairie).

Ma question est donc : comment faire pour qu'une fonction d'une librairie dynamique puisse utiliser les méthoses d'un objet passé en parametre ?

J'epsere etre clair, je vous donnerais les listing de code si nécessaire.

Merci d'avance.
14/02/2007, 14h15
hiko-seijuro

ton os est windows ? linux ? autres ?
14/02/2007, 14h46
eponyme

Mon OS est linux, pardon de ne pas l'avoir précisé.
J'allais donner l'url du lien que j'ai utilisé pour commencer ce travail quand j'ai vu ton pseudo... c'est donc ton tuto ;)

J'ai aussi suivi celui ci http://www.linux.com/howtos/C++-dlop...solution.shtml avant de lire le tiens.

Je pourrais montrer du code ce soir une fois chez moi :)
14/02/2007, 17h20
hiko-seijuro

montre le code oui :)

ok, donc dans mon projet (un bot irc en fait), j'ai un fichier "plugin.hpp" (jamais reussi à diviser en .cpp/.h), le voici :

Code:

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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
 
#ifndef PLUGIN_HPP
 
#define PLUGIN_HPP
#include "message.h"
#include "ircprotocol.h"
#include <vector>
#include <string>
using namespace std;
class Plugin;
typedef enum {
IN_LOOP,IN_COMMAND_HANDLER,IN_TYPE_HANDLER,IN_BEFORE_TREATMENT,IN_ALL_MSGS,OUT_ALL_MSGS
} func_type;
typedef bool (*PluginFunction)(Message*,Plugin *,IRCProtocol*);
typedef Plugin *(*plugin_constructor)();
typedef void (*plugin_destructor)(Plugin*);
typedef struct 
{
	string name;
	void * handle;
	Plugin* object;
	plugin_constructor creator;
	plugin_destructor destructor;
} pPlugin;
typedef struct 
 
{
	void * handle;
	string highlightedWord;
	Plugin* object;
	func_type type;
	string symbole;
	PluginFunction function ;
 
}StructFunctionStorage;
 
class Plugin {
protected:
	string author;
	string description;
	string version;
	string name;
public:
   Plugin()
	{
		this->author = "";
		this->description = "";
		this->version = "";
		this->name = "";
	};
   virtual ~Plugin(){};
	virtual vector<StructFunctionStorage> getFunctions()=0;
	string getAuthor()
	{
		return this->author;
	};
	string getDescription()
	{
		return this->description;
	};
	string getVersion()
	{
		return this->version;
	};
	string getName()
	{
		return this->name;
	};
	bool checkMembers()
	{
		if ( this->getAuthor() == "" )
			return false;
		if ( this->getDescription() == "" )
			return false;
		if ( this->getVersion() == "" )
			return false;
		if ( this->getName() == "" )
			return false;
		return true;
	};
};
#endif

J'ai ensuite un fichier "ping.h" :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
 
#ifndef PING_H
 
#define PING_H
#include "../plugin.hpp"
#include <iostream>
using namespace std;
 
class Ping : public Plugin
{
public:
	Ping();
	vector<StructFunctionStorage> getFunctions();
};
 
#endif

et son .cpp correspondant :

Code:

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
36
37
 
#include "ping.h"
 
Ping::Ping()
{
	this->author = "eponyme";
	this->description = "Make the bot answer \"pong\" to \"ping\" message";
	this->version = "0.1";
	this->name = "ping";
}
 
vector<StructFunctionStorage> Ping::getFunctions()
{
	vector<StructFunctionStorage> funcs;
	funcs.push_back((StructFunctionStorage){NULL,"",this,IN_ALL_MSGS,"pong",NULL});
	return funcs;
}
 
extern "C"
{
	Plugin *contruct()
	{
		Plugin* toto = new Ping();
		toto->getFunctions();/*test pour voir si j'etais bien capable d'utiliser un objet créé*/
		return toto;
	}
	void destroy(Plugin*p)
	{
		delete p;
	}
	bool pong (Message*m,Plugin*p,IRCProtocol*i)
	{
		p->getFunctions();
		//m->getSplit();
               return true; //modifier !
	}
}

C'est dans la derniere fonction, "pong" que ca plante. si je decommente le "m->getSplit()" ,alors je ne peux plus ouvrir ma librairie (comment on dit DLL sous linux ? :mrgreen:

Je sais que mon fichier "plugin.hpp" est un peu "crade", notemment a cause de tous les typedef mis n'importe ou. C'est temporaire, mais j'ai tellement "d'inclusion croisées" que j'étais content que ca fonctionne de cette facon :)

N'hésite pas a me demander d'autre description de classes si tu le souhaite.

Merci pour ton aide

epo

14/02/2007, 23h12
hiko-seijuro

comment ca tu peux plus l'ouvrir ? il fait quoi ?
15/02/2007, 00h13
eponyme
Quand le fait le dlopen, le handle est à 0.
ensuite si je fais un dlsym pour reucpérer la fonction de cosntruction, j'ai ca :
Code:

1 2 Cannot load library ping.so:plugins/ping.so: undefined symbol: _ZN11IRCProtocol4pongESs
Si je laisse commentée la ligne dont j'ai parlé, ca passe sans souci.
15/02/2007, 01h20
nicroman

Citation:

Envoyé par eponyme

C'est dans la derniere fonction, "pong" que ca plante. si je decommente le "m->getSplit()" ,alors je ne peux plus ouvrir ma librairie

Essayes de faire un graphe sur un bout de papier (c'est dingue ce que la programmation objet peut bouffer en papier :mouarf: ), avec les relations des objets entre eux... qui utilise quoi et comment.

Si un objet ObA d'une librairie LibA, utilise un objet ObB, alors ou bien ObB est dans la même librairie (LibA), ou dans une autre librairie dont LibA dépend.

Dans le cas des plug-ins, en général c'est:
library-with-plugin-definition.dll
plugin1.dll (qui utilise library-with-plugin-definition.dll)
plugin2.dll (qui utilise library-with-plugin-definition.dll)

program.exe (qui utilise library-with-plugin-definition.dll, et peut charger plugin1.dll et plugin2.dll)

Tu as plus qu'à remplacer dll avec so ;), ca marche pareil.

A noter que si la définition du plug-in n'introduit pas de code, alors le simple .h peut suffire. Mais dans ton cas, Message et IRCProtocol semblent venir d'ailleurs ! :D
15/02/2007, 12h24
eponyme

Je vois pas trop :/
IRCProtocol vient bien d'ailleurs, mais le ircprotocol.h est inséré dans plugin.hpp, d'ailleur la compil passe paraitement :s
15/02/2007, 12h41
quicky2000

le fait que la compil passe parfaitement ne veut rien dire... dans ton cas il s agit d un probleme de link.
Deja est ce que tu sais dans quel librairie est defini le symbole qui te manque ? et ensuite est ce que la librairie que tu essaies de charger possede une dependance sur la librairie definissant ce symbole ?

le symbole qu'il me manque est défini dans une classe de mon projet.
la libvrairie que je charge est "a moi", et a par le fait qu'elle utilise cette méthode, il n'y a pas d'autres dépendances.
Je crois que je commence à comprendre lol. en fait quand je build ma dll, je dois lui indiquer "la référence" vers l'objet qu'elle utilise ?
Si ca peux donner une piste, voici mon makefile :
Code:

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 CC=g++ SRC_DIR=src PLUGS_SRC_DIR=src/plugins PLUGS_DIR=plugins CFLAGS=-Wall -ansi DFLAGS=-shared LDFLAGS=-Wall -ansi -ldl -lpthread EXEC=monExe all: $(EXEC) libs monExe: $(SRC_DIR)/main.o $(SRC_DIR)/channel.o $(SRC_DIR)/botkernel.o $(SRC_DIR)/configurationfile.o $(SRC_DIR)/message.o $(SRC_DIR)/flowmanager.o $(SRC_DIR)/main.o $(SRC_DIR)/socket.o $(SRC_DIR)/tools.o $(SRC_DIR)/ircprotocol.o $(CC) -o $@ $^ $(LDFLAGS) %.o: %.c $(CC) -o $@ -c $< $(CFLAGS) libs: $(PLUGS_SRC_DIR)/ping.so %.o: %.c $(CC) -o $@ -c $< $(CFLAGS) %.so: %.o $(CC) $(DFLAGS) -o $@ $< mv $(PLUGS_SRC_DIR)/*.so $(PLUGS_DIR)/ clean: rm -f $(SRC_DIR)/*.o $(SRC_DIR)/*.so $(PLUGS_SRC_DIR)/*.o $(PLUGS_SRC_DIR)/*.so clean_plugins: rm -f $(PLUGS_DIR)/*

15/02/2007, 18h56
quicky2000

Je connais pas ton code mais d apres le message d erreur ce qu il te manque c est l implementation de la metode pong dans ta classe IRCprotocol. Tu es sur que tu ne l as pas oublie ? parce qu une erreur comme ca me fait penser au cas ou on declare une method sans jamais la coder.
J ai quand meme de gros doutes sur l histoire de la ligne commentee ou decommentee parce que ca ne doit avoir aucun impact sur la definition ou non du symbole pong
15/02/2007, 19h45
eponyme

la méthode pong n'est pas implémentée dans ircprotocol, c'est une fonction que je declare ici poru qu'elle soit dispo dans ma dll.

Sinon ben la ligne quand elle est commentée, ca passe, sinon ca passe pas. C'est plutot de la classe message dont il s'agit en fait dans mon exemple.
15/02/2007, 20h32
quicky2000

hum.....
la declaration de ta/tes methodes pong se trouve(nt) ou ? ( dans une classe ? en dehors d une classe ?
ou se trouve(nt) la/les implementations correspondant a chaque prototype ?
15/02/2007, 21h00
eponyme

:s
je n'ai pas de prototype pour la fonction "pong".

Elle est placée dans le "extern C" car je souhaite qu'elle soit accessible avec l'ouverture de la dll, mais elle n'est déclarée nulle par ailleurs.

Je l'ai mise comme "construct" et "destroy".

Pour le reste, ca se trouve dans plugin.hpp.

Pour les classes IRCProtocol et Message, ce sont des classes. Le ".h" est inclu dans "plugin.hpp".
16/02/2007, 15h19
hiko-seijuro

j'ai un peu du mal a suivre. Quelle est la fonction qui est exportée ? par qui elle est chargée ? ou elle est appelée ?
16/02/2007, 21h27
eponyme
oki, je reprends :)

Alors dans mon projet, j'ai une classe, qui s'appelle "Message".
J'ai une autre classe qui s'appelle "Plugin" (de laquelle deriverons d'autres classes).
Ma classe "Ping" dont je vous ai donné le code, est dérivée de la classe plugin. Je souhaite exporter cette classe dans une bibliotheque dyndamique. Cette "dll" exportera, proposera, (je ne sais pas comment dire) 3 fonctions : contruct,destroy et pong. (elle sont dans le "extern C" de ping.cpp).
Construct et destroy permettrons de construire et detruire l'objet exporté par la dll (comme dans le tuto).
pong est elle une autre fonction, qui pour effectuer un traitement particulier, nécessite des pointeurs sur des objets qui ont été instancié dans el programme. en l'occurence : Message et IRCProtocol.
Pendant l'execution du programme, je charge ma dll dans le code "kernel" du bot irc.

Il se trouve que si je commente la ligne utilisant l'objet Message, pas de probleme d'ouverture de dll. En revanche, si je la décommente (pour utiliser mon objet dont j'ai passé l'adresse donc), j'ai une erreur. je m'excuse mais le message que j'ai mis précédemment n'est pas exact, car il ne correspond pas au code que j'ai présenté, voici celui que j'obtiens :
Code:

1 2 Cannot load library ping.so:plugins/ping.so: undefined symbol: _ZN7Message8getSplitEv
On voit donc qu'il "coince" sur l'utilisation de l'objet.

J'espere avoir été plus clair :)

merci pour l'aide que vous apportez :)
17/02/2007, 00h07
quicky2000

ah ben la effectivement c est plus coherent avec ce que tu disais sur la mise en commentaire de la ligne :D
d apres le message d erreur je dirai qu il ne trouve pas l implementation de la methode getSplit et c est de la que vient le probleme. Si tu n utilises pas la methode il est normal que le linker ne bronche pas si il ne la trouve pas.
Deja premiere chose tu es sur d avoir implemente la methode getSplit et si oui dans quel fichier ? et si c est un fichier exterieur a ta lib pourquoi tu ne l integres pas dedans ?
Une chose a faire aussi serait de verifier si la methode est definie ou non dans ton executable. Tu peux faire cela via la commande nm

dsl pour l'erreur :). elle vient du fait que j'ai supprimé des portions de code inutiles pour l'exemple, et que j'ai recupéré le mauvais message -_-.
Pour l'impléementation de "getSplit()", pas de soucis. Je l'utilise à ne nombreux endroits dans mon projet, elle est bien implémentée. Dailleurs j'ai essayé avec d'autres méthodes de la classe "Message" => meme souci (et avec d'autres objets). Elle est implémentée dans "message.cpp", déclarée dans "message.h", fichier étant lui meme inclu dans "plugin.hpp", fichier lui meme inclu dans "ping.h", lui meme inclu dans "ping.cpp". *herm*

Pour finir, voici ce que j'ai récupéré comme infos avec "nm" :
Code:

1 2 3 4 5 6 7 8 $ ./monexe Cannot load library ping.so:plugins/ping.so: undefined symbol: _ZN7Message8getSplitEv $ nm monexe | grep _ZN7Message8getSplitEv 08053384 T _ZN7Message8getSplitEv $ nm plugins/ping.so | grep _ZN7Message8getSplitEv U _ZN7Message8getSplitEv $
Si je comprends bien ce que je vois, (:)) le symbole est bien défini dans ma bibliotheque mais il n'y a pas d'adresse a coté (donc en fait mal définie ?)

Plus on avance et plus j'ai effectivement l'impression que ca vient de la facon dont je "construit" mon .so.

je reprends ici la partie de mon makefile contruisant la lib :
Code:

1 2 3 4 5 6 libs: $(PLUGS_SRC_DIR)/ping.so %.o: %.c $(CC) -o $@ -c $< $(CFLAGS) %.so: %.o $(CC) $(DFLAGS) -o $@ $<
Merci pour ton aide :)

Une solution pourrait etre d integrer message.o dans ta librairie au lieu de le mettre dans l executable...
par contre si ton executable veut pouvoir utiliser la classe message sans charger ping.so je pense qu il faut faire ce que nicroman preconisait des le depart:

Citation:

Envoyé par nicroman

Si un objet ObA d'une librairie LibA, utilise un objet ObB, alors ou bien ObB est dans la même librairie (LibA), ou dans une autre librairie dont LibA dépend.

Dans le cas des plug-ins, en général c'est:
library-with-plugin-definition.dll
plugin1.dll (qui utilise library-with-plugin-definition.dll)
plugin2.dll (qui utilise library-with-plugin-definition.dll)

program.exe (qui utilise library-with-plugin-definition.dll, et peut charger plugin1.dll et plugin2.dll)

Tu as plus qu'à remplacer dll avec so ;), ca marche pareil.

En ce qui concerne les infos renvovyées par nm :
Citation:
Envoyé par eponyme
Pour finir, voici ce que j'ai récupéré comme infos avec "nm" :
Code:

1 2 3 4 5 6 7 8 $ ./monexe Cannot load library ping.so:plugins/ping.so: undefined symbol: _ZN7Message8getSplitEv $ nm monexe | grep _ZN7Message8getSplitEv 08053384 T _ZN7Message8getSplitEv $ nm plugins/ping.so | grep _ZN7Message8getSplitEv U _ZN7Message8getSplitEv $
Si je comprends bien ce que je vois, (:)) le symbole est bien défini dans ma bibliotheque mais il n'y a pas d'adresse a coté (donc en fait mal définie ?)
Le U devant ta methode pr la libraire signifie Undefined c est a dire que tu appelles une methode non implementee dans ta librairie.
Si tu recommentes ta ligne qui pose probleme l info disparaitra de nm car tu n utilises plus la methode

17/02/2007, 12h26
eponyme
hey !
je pensais l'avoir essayé, j'avais du me tromper. Apres avoir lu ton post, j'ai fait :
Code:

1 2 3 g++ -c ping.cpp g++ -shared -o ping.so ping.o ../message.o ../tools.o
et plus d'erreurs \o/

En revanche nm me dit qu'il y a encore des "U" dans mon so (qui ne semblent pas venir de mon code), je dois m'inquiéter ?

J'ai donc modifié mon makefile, mais j'ai donc j'ai les .o pour l'exe, et pour les so.

La solution proposée par nicroman semble donc etre meilleure.
En revanche je ne vois pas comment s'articule les choses.
Au lieu d'avoir une classe "Plugin" dans mon projet, je l'exporte dans une dll que j'ouvre ensuite dans mon projet ? et ensuite mes plugins devrons ouvrir cette dll ?
19/02/2007, 10h39
hiko-seijuro

ca serait pas plutot dans l'executable ou il serait normal d'avoir un U le symbole etant définit dans le .so
20/02/2007, 02h06
nicroman

Citation:

Envoyé par eponyme

En revanche je ne vois pas comment s'articule les choses.
Au lieu d'avoir une classe "Plugin" dans mon projet, je l'exporte dans une dll que j'ouvre ensuite dans mon projet ? et ensuite mes plugins devrons ouvrir cette dll ?

Bon en fait, je ne connais pas le probleme à fond sous Linux, mais mon petit doigt me dit que c'est exactement pareil (j'ai un peu oublié mes années sur Bull 8-) ). Tu traduiras .exe en -rwx------ et .dll en .so :)

Un .exe n'exporte rien... d'accord ?
Donc si tu as des classes définies dans ton .exe, elle ne sont visibles de personne.
Si une .dll a besoin (importe) une référence, elle doit être exportée quelque part (donc dans une autre .dll).
Attention, un simple pointeur n'est pas une référence, mais un appel de fonction direct (sans passer par un "Fonctor", ou un pointeur de fonction donc) oui !

Si ta class Pong (dans une .dll) utilise des méthodes IRCProtocol::toto, et Ping::tata (ce qui inclut le constructeur), alors elle doit pouvoir importer ces fonctions, ce qui veut dire que ces fonctions doivent être dans une .dll !

Il se peut (ca m'est déjà arrivé), que ton .exe se retrouve juste à faire:

Donc tu as
- une .dll "Ping" (avec Ping, IRCProtocol, whatever...).
- une .dll "Pong" (avec Pong, ...) qui utilise Ping.dll
- un .exe qui utilise Ping.dll, et peut charger dynamiquement Pong.dll

Et voilà, plus de référence circulaire (et on m'a toujours dit: références circulaires, problêmes dans l'air :mouarf: ).
21/02/2007, 12h53
eponyme

Je vais me renseigner sur tout ca,
en attendant ca fonctionne parfaitement.

Merci pour l'aide et le temps consacré.

:)