A vrai dire, c'est parce que j'ai sans doute manqué quelque peu de précision dans mes écrits.
Pour te permettre de comprendre l'ensemble du problème, il semble utile de t'expliquer clairement toute la problématique des bibliothèques dynamiques, du moins sous windows.
En effet, pour qu'une fonction présente dans une bibliothèque dynamique soit utilisable de l'extérieur, il faut qu'elle soit exportée par la bibliothèque dynamique.
Et, "fatalement", pour qu'un programme sache qu'il a affaire à une fonction venant de la bibliothèque dynamique, il faut lui demander... de l'importer.
Cela signifie que, lorsque tu compile ta bibliothèque, la déclaration (et la définition) des fonctions doit être du genre de
typeDeRetour __decl(dllexport) nomFonction(/*paramètres éventuels */)
mais, que de l'autre coté, lorsque tu fournis le fichier d'en-tête à l'utilisateur de ta bibliothèque de manière à ce qu'il puisse l'utiliser de son coté, son compilateur doit trouver la déclaration (et la définition) sous la forme de
typeDeRetour __decl(dllimport) nomFonction(/*paramètres éventuels */)
La différence étant minime, autant attirer ton attention dessus...
Dans le premier code, ce qui est se trouve entre les parenthèses qui suivent __decl est dllexport, alors que c'est dllimport dans le second code.
Evidemment, tu me diras qu'il est tout à fait possible de prévoir deux fichiers d'en-tête différents (vu que ce sont les seuls qu'il faut fournir en plus de la dll), l'un qui sera utilisé pour compiler la dll et l'autre qui sera fournit à l'utilisateur...
Mais, même si c'est possible, il faut quand même avouer que ça représente pas mal de travail pour pas grand chose
L'idée est donc d'appeler saint préprocesseur à la rescousse, car il va gérer cela très facilement.
L'idée est, tout simplement de lui dire que, si on lui indique qu'il est occupé à travailler à la compilation de la bibliothèque dynamique, il doit remplacer un terme choisi pour être unique (ici MYEXPORT) par __decl(dllexport), et que, sinon, il doit remplacer ce terme par ... __decl(dllimport).
Il reste alors juste à savoir comment nous allons signaler au préprocesseur que nous sommes occupés à compiler la dll...
Ce sera fait en fournissant une option -D (ou /D selon le compilateur) pour define, suivie d'un terme explicite, par exemple "BUILD_DLL", et cela prendrait donc la forme de
gcc -DBUILB_DLL(tout le reste de l'instruction)
Au final, l'instruction préprocesseur serait du genre de
1 2 3 4 5
| #ifdef BUILD_DLL
#define MYEXPORT __decl(dllexport)
#else
#define MYEXPORT __decl(dllimport)
#endif |
que l'on veillera à placer dans un fichier qui sera inclus partout où risque d'apparaitre le fameu MYEXPORT
Si tu avais pris la peine de lire le lien fourni par Médinoc, tu n'aurais pas eu moins d'explications
Tu peux aussi envisager de lire le chapitre dédié à la gestion des dll dans l'excellent article de Laurent Gomilla, sans oublier que ou la fonction rechercher sur le forum sont des amis très utiles pour les membres du forum.
Evidemment, s'il reste quelque zones d'ombre malgré tes recherches personnelles, n'hésite pas à nous faire part de tes interrogations
Au fait, une petite question en passant: y a-t-il une raison primordiale qui te fasse te tourner vers une DLL plutôt que vers une bibliothèque statique, dont la gestion reste malgré tout bien moins complexe
Partager