Discussion :

[pierre.chatelier]

Bonjour,

Je voudrais mettre au point une structure de développement sur laquelle je me casse les dents depuis deux jours. Je ne sais pas résoudre entre autres les divers problèmes de link ijw/clr/pure/pas pure (c'est une horreur)
Voici :
J'ai une base de code en C++ standard, agrémenté parfois de quelques utilisations de classes C++/CLI (system::string^, etc.). Je voudrais en faire une DLL utilisable dans d'autres projets (disons core.lib/core.dll; un jour il faudra que je comprenne pourquoi la génération d'une dll produit aussi un .lib)
J'ai un projet ("solution" en visual) consituée de deux sous-projets
-la redéfinition d'un contrôle utilisateur (UIControl)
-le programme principal
Ces deux projets ont besoin du code de core.dll

Initialement, ça marchait bien :
La dll était compilée en CLR (ni pure ni safe), décorée des divers declspec(dllexport)
Le contrôle utilisateur était aussi en CLR (ni pure ni safe) et importait les headers en remplaçant les dllexport par dllimport, linkant avec core.lib, et utilisant #using core.dll (merci au tuto de nico-pyright)
Le programme principal faisait de même

Et puis un jour, le designer du programme principal s'est mis à ne plus reconnaître le contrôle utilisateur. Ce n'est pas faute d'avoir regénéré le projet, refait l'importation du contrôle dans la boîte à outil... rien à faire. Et puis finalement, en supprimant le contrôle de la boîte à outil pour le réimporter ensuite, je suis retombé sur l'erreur de chargement HRESULT machin qui apparemment vient du fait que mon usercontrol.dll n'est pas clr:pure

J'ai donc décidé de refaire un peu ça.
-Pour une raison que je ne m'explique pas, core.dll compile très bien en clr:pure (je croyais que le C++ et les pointeurs l'en empêcheraient). Au passage, j'ai dû supprimer les declspec(dllexport).
-De même, mon usercontrol compile en clr:pure (en virant les dllimport des headers)
-par contre, ça ne linke plus. Un obscur lnk2001 sur 5 ou 6 fonctions de ma dll l'en empêche. Il n'y a aucune raison pour ça, ces fonctions sont banales, et je n'ai pas dupliqué les déclarations dans différents headers, donc pas d'incohérence possible.
-En fouillant le net, il paraît qu'il faut rajouter msvcmrt.lib, mais dans ce cas, ça n'essaye même pas de linker (mscvcmrt.lib est en ijw, incompatible clr:pure).

J'ai essayé des tas de configurations pure/pas pure, rien n'y fait, je n'y arrive pas.

Quelqu'un aurait-il des lumières ?

Merci

+
Chacha

[nico-pyright(c)]

quelles sont les erreurs ?

[pierre.chatelier]

quelles sont les erreurs ?

error LNK2001: symbole externe non résolu
"public: void __clrcall EXSingletonManager::destroySingletons(void)" (?destroySingletons@EXSingletonManager@@$$FQAMXXZ)

et idem pour quelques autres fonctions d'autres classes (c'est très varié : une virtuelle, une statique, un constructeur...)

Prenons l'exemple de cette fonction: elle n'est pas inline, elle est dans une classe. Le code est dans un .cpp, et le .h est ainsi :
class EXSingletonManager {
...
public: void destroySingletons(void);
}...

J'avais pensé qu'il pouvait s'agir de fonctions décorées/inlinées différemment dans le .obj en fonction des optimisations, mais j'ai bien mis les même, j'ai essayé de les désactiver, etc. Rien à faire

+
Chacha


[edit]
Tiens, ben en fait, core.dll ne génère plus de core.lib, puisque j'ai viré les dllexport qui sont incompatibles avec le clr:pure...
J'ai aussi essayé de forcer le __clrcall devant les fonctions problématiques, mais rien ne change.
[edit2]
Et si je compile core.dll en clr (pas pure), c'est pareil

[nico-pyright(c)]

quand tu changes de mode de compilation, la convention d'appel par défaut change.
Si tu fais des classes natives comme semble l'etre EXSingletonManager, tu peux essayer en définissant explicitement la convention d'appel, à stdcall par exemple

mais peut-etre serait-il plus judicieux d'en faire des classes managées qui seront plus facilement intéropables ensuite

[pierre.chatelier]

quand tu changes de mode de compilation, la convention d'appel par défaut change.
Si tu fais des classes natives comme semble l'etre EXSingletonManager, tu peux essayer en définissant explicitement la convention d'appel, à stdcall par exemple

Ça ne change absolument rien ! Toujours les mêmes erreurs de link sur les mêmes fonctions !

mais peut-etre serait-il plus judicieux d'en faire des classes managées qui seront plus facilement intéropables ensuite

Ce n'est pas mon but. Je ne veux pas réécrire en code managé toutes les classes C++ standard que j'utilise, au contraire; je veux le plus de code standard possible. En réalité, le peu de code managé dans ces classes est encapsulé par un #ifdef VISUAL ... #endif : j'utilise les types natifs quand c'est possible, en fonction du système.

+
Chacha

[pierre.chatelier]

Je pense à quelque chose...
Est-ce mafaçon d'importer les headers qui ne va pas ?

Je m'explique : dans le projet principal, même si je suis lié à ma dll, il me faut bien les headers pour utiliser les classes. Or,le compilateur va peut-être compiler certaines méthodes lors du parsing du header, et décorer différemment, ce qui donne un link "symbole non trouvé". Mais comment faire, alors, pour lui faire "lire" le header d'une classe en lui disant "ça mon coco, ce sont les déclarations d'une dll compilée, peut-être, en clr pas pure" (ce qui n'est pas le cas, mais bon) ? Il y a une astuce ?

+
Chacha