dynamic_cast et librairies partagees

Bonsoir a tous,

(desole pour les accents, qwerty oblige)

apres un week end de recherche je me suis resolu a venir vous demander de l'aide.

Je bloque sur une histoire de dynamic_cast d'une classe qui m'est retournee par une fonction exportee d'une librairie partagee (..ouf)

Je m'explique.

Le core du programme doit pouvoir loader des modules (.so - je travail sous linux la). Ces modules sont tous issus d'une interface generique de cette maniere la:

IModule
--> IModuleTypeA
--> IModuleTypeB
--> IModuleTypeC

(ou IModuleTypeA, TypeB, et TypeC, heritent de IModule).

ensuite, dans chaque .so, l'utilisateur herite d'un des types de module (disons TypeA), et implemente les methodes heritees.

Bref une architecture tres classique d'heritage.

Dans le core du programme, chaque module qui est charge est stocke dans une std::list<IModule*>.

Plus tard lors de l'execution du programme, je souhaite acceder a des methodes propres a chaque Type de module en "down-castant" un IModule* dans son IModuleType'X' (en considerant que je sais son type pour faire le bon dynamic cast).

Ceci est donc une utilisation relativement classique de l'heritage, a l'exception pret du fait que la classe qui est implementee viens d'une librairie partagee.

Le probleme est qu'il m'est impossible de dynamic_caster mon IModule* en IModuleTypeA. A noter qu'une typeid sur mon IModule* en le dereferencant me renvoi le bon type de la bonne classe (celle qui est contenue dans le module).

J'ai fait pas mal de tests, et la pour l'instant je seche.

Si quelqu'un avait un debut de piste, aucune de mes recherches sur le net n'ayant ete fructueuses.

Merci d'avance a tous.

Bonne soiree.

Je ne connais pas parfaitement les rouages du RTTI (encore plus sous Linux), mais d'aprés ce que j'en sais pour Windows, il existe une option du compilateur pour activer ou non la génération de code, la compilation et l'utilisation du RTTI.

Est-ce que par hazard, entre tes bibliothèques dynamiques et ton programme principal tu n'aurais pas des options de compilation différentes ?

Enfin tu peux nous dire exactement là ou ça coince (compilation, exécution, essage d'erreur, ...).

en fait on a resolu le probleme sur un coup de chance monstrueux au detour d'une recherche sur le net.

maintenant nous sommes en train de nous demander comment configurer Visual pour que le build d'une DLL ne cherche pas a resoudre les symbols des fonctions qui appartiennent au core du projet.

Dans l'etat actuel des choses, chaque dll sous windows est linkee avec certains des objects du Core. Nous avons trouve une maniere de regler ce probleme sous linux, mais nous l'avons toujours sous windows.

auriez-vous une idee?

Est-ce que tu pourrais mettre le lien vers la page que tu as trouvée ? Ainsi si d'autres personnes ont le même problème que toi et lisent ce post, ils auront tout de suite la solution.

Citation:

---

Envoyé par samball

Dans l'etat actuel des choses, chaque dll sous windows est linkee avec certains des objects du Core. Nous avons trouve une maniere de regler ce probleme sous linux, mais nous l'avons toujours sous windows.

---

Je vois parfaitement ce vous faites, mais par contre je ne vois pas le problème.... Une erreur de compilation, d'exécution, un code d'erreur ?

Voila l'article: http://www.linuxjournal.com/article/3687

Et sinon pour ce qui concerne windows, voila en detail le probleme.

Dans le code de notre projet, nous dispons de Singleton qui permettent en vrac de traiter tout ce qui concerne le log de message de debug, la configuration ou autre.

Nous aimerions mettre ces singletons a disposition de nos DLL.

Le probleme que nous avions a ce moment la venait du fait que lorsque nous reclamions une instance d'un des singletons dans une dll, etant linkee en static avec l'object contenant le Singleton, cela retournait une nouvelle instance.
Par exemple, le singleton de configuration etait rempli dans le core, et lorsque nous l'appelions dans la dll, cela en refaisait un nouveau (donc vide de toute configuration).

Pour resoudre ce probleme avons passe des references sur nos singletons a chacune de nos dll.


Or sous linux, nous avons reussi a linker nos dll uniquement avec les objs de la dll, en lui disant que tout ce qu'il aura besoin se trouvera dans le core (ce qui fait que le load de la dll ne renvoyait pas d'erreur de symbol non resolu).
D'une pierre deux coup, cela resolvait aussi le probleme des Singletons, qui maintenant sont accessibles depuis les dll sans recreer une instance propre a la dll.

Nous cherchons donc un moyen de reproduire ce fonctionnement sous Windows en fait:
que le compilo (et le linker) ne nous dise pas que nous avons des symbols non resolus, et que l'appel aux singletons se fasse sur les instances crees par le core.

Citation:

---

Envoyé par samball

maintenant nous sommes en train de nous demander comment configurer Visual pour que le build d'une DLL ne cherche pas a resoudre les symbols des fonctions qui appartiennent au core du projet.

---

Il me semble que c'est impossible si tu les utilises.

Citation:

---

Envoyé par samball

Dans l'etat actuel des choses, chaque dll sous windows est linkee avec certains des objects du Core. Nous avons trouve une maniere de regler ce probleme sous linux, mais nous l'avons toujours sous windows.

---

J'ai cherché quelque chose de similaire à ce que tu veux; le problème étant que sous linux, les fonctions sont plus ou moins automatiquement exportées puis importées de l'exécutable de ce que j'en ai compris (je suis loin de connaître ça, mais c'est ce qui m'a été expliqué et qui causait des problèmes lors d'un portage sur Windows).
La seule façon de faire quelque chose d'équivalent est de générer un .lib en même temps que tu génères ton application. Ca implique d'utiliser les attributs _declspec( dllimport ) et __declspec( dllexport ) sur les en têtes des classes que tu veux exporter.
Ce faisant, une lib contenant ces symboles est générée dans le même chemin que l'application il me semble. Si tu veux la renommer/déplacer ailleurs et que tu utilises VC++, regardes du côté du flag /IMPLIB.
Il te suffit pour utiliser les classes de lier avec ce .lib et c'est bon.

Apres recherches, il semblerait effectivement que la methode que tu evoque soit la seule methode viable.

il nous faut donc mettre des __declspec(dllimport) et __declspec(dllexport) devant ces fameuses fonctions ce qui generera donc bien ce fameux .lib avec lequel nous linkerons nos dll.

Merci a tous pour votre aide :)

Bonne soiree.

Ca c'est pour le pbl de l'export de fonctions et classes au niveau de la DLL (autrement dit quel sont les symboles qui seront accéssibles depuis mon programme lorsqu'il chargera la DLL).

Maintenant tu as 2 autres pbs. qui ne seront pas forcément réglés avec le "__declspec()" :

1 - comment éviter que tes 2 singletons soient instanciés 2x (dans l'EXE et dans le DLL)

2 - comment dire à la DLL que le singleton qu'elle doit utiliser est déjà dans l'EXE

Pour faire court et en attendant (car un peu de code m'aiderai), le pb1 peut surement se régler à coup de déclaration "extern".

Le pb2 par contre le seul moyen est de passer par une fonction dont la sémantique est "une fonction de référencement (in english registering)".
En gros, tu va faire de l'effet de bord (en passant à la DLL) une bonne fois pour toutes le pointeur sur le singleton instancié dans ton EXE. La DLL va sauver ce pointeur dans une variable gloable (non exportée !) et va la réutiliser partout. Ainsi tu simplifie le prototype de toutes tes fonctions dans la DLL ! C'est pas cool ? :yaisse3: