Discussion :

[Niklaos]

Bonjour,

Je suis en train de programmer un serveur generique.
Ce serveur met a dispositions des DLLs qu'il charge une class permetant les interactions avec les autres DLLs et le network.

Seulement voila je rencontre un petit souci avec la compilation des DLLs. Ces dernieres ne doivent pas contenir le code du serveur. Mais elles doivent quand meme y faire appelle.

J'ai donc include les .h contenant le typages des fonctions dans la DLL.

A la compilation de la DLL VS me dit "unresolved external symbol" ce qui veut dire si je comprends bien qu'il ne trouve pas le corps de la fonction !

Comment dire a Visual que le Linking doit se faire au chargement de la DLL et pas avant ?

J'ai fais un petit test sous Linux et cela fonctionne sans souci, il fait bien le linking au moment du chargement du .so !

Les Pros de VS ont il une idee ?

Merci d'avance

[screetch]

sous linux les DLL (enfin les SO) peuvent utiliser les symboles du programme qui les charge, ce qui n'est pas le cas sous windows.
En revanche, sous windows, un executable est quasiment equivalent a une DLL. lorsque tu compiles ton executable sous visual C++, tu peux demander a generer le .lib avec, ce qui te permet de créer une DLL qui utilise l'executable comme DLL.

Au runtime, l'executable va charger la DLL et cette DLL va se lier a l'executable (qui est deja chargé, donc bingo) et on a ainsi le meme comportement sous windows et linux.
En revanche, il va peut etre falloir apporter quelques modifs a ton build, et également retravailler ton executable pour exporter tous les symboles dont ta DLL a besoin, ca peut etre un peu fastidueux (il va falloir utiliser __declspec(dllexport) partout dans l'exe)

[Niklaos]

Ok ...

Si je comprends bien j'ai juste a rajouter le __declspec(dllexport) devant les methods dans l'exe et faire en sorte que l'exe soit compile avant la Dll avec les dependances ?
Parceque le linker n'arrive toujours pas a completer la compilation ...

Sinon visiblement y'a moyen d'eviter les __declspec(dllexport) devant toutes les methods parceque ca risque de faire un code attroce quand je vais le porter sur Linux.

D'apres la msdn il y a plusieurs facons de declarer les exports :

• The __declspec(dllexport) keyword in the source code
• EXPORTS statement in a .def file
• An /EXPORT specification in a LINK command

L'autre solution que j'ai trouve en fouillant, c'est d'utiliser les .exp !

Normalement les .exp permetent de resoudre les problemes d'appelles circulaires. Genre A a besoins d'une method dans B et B a besoins d'une method dans A.

Tu as entendu parle de cette solution ?

[screetch]

pas vraiment, je trouve perso que le declspec(dllexport) est ce qu'il y a de plus portable et de plus propre car ca permet de selectionner quelles fonctions doivent etre exportées. l'equivalent sous linux est __attribute__((visibility=default)) je crois qui te permet de publier seulement quelques symboles. ca donne quelques macros a ecrire mais ca rend le code plus propre je trouve.
je crois que les fichier exports ne marchent pas en C++ a cause du mangling pas pas sûr.

[Médinoc]

Sinon, plutôt qu'avoir une dépendance circulaire, pourquoi ne pas proposer tes fonctions à la DLL en callback ?
Par exemple, tu lui files un pointeur d'interface...