Discussion :

[vdiem]

Bonjour,

C'est la première fois que je viens sur ce forum. J'ai en effet rencontré un petit problème sous Borland C++ 6.0, au moment de l'édition de lien avec une DLL.

Mon projet consiste en :
- un noyau de calcul réalisé au moyen d'une DLL écrite en ADA (GNAT).
- une IHM simple (affichage du courbes, sélection de fichiers) écrite en Borland C++.

Dans le projet, la DLL est tout simplement liée en incluant le fichier ".lib", créé grâce à l'outil Borland "implib". Et au moyen d'un fichier déclarant les fonctions grâce à :
'extern "C" {
float Get_Power(Line);
....

}'.

Jusqu'à présent tout allait bien. Les échanges de données se faisaient correctement. Mais en voulant ajouter une nouvelle fonction à l'interface un phénomène étrange est apparu, au moment de l'édition de lien, la DERNIERE FONCTION dans l'odre ALPHABETIQUE n'était plus vu par le lieur de BORLAND (la 64e fonction exactement). Et le message suivant apparaît : "UNRESOLVED EXTERNAL : _Le_Nom_de_la_64e_fonction".

Ce qui est interressant c'est que :
1) si je rajoute 2, 3 ou 4 fonctions supplémentaires dans la DLL, le même message d'erreur se produit : "UNRESOLVED EXTERNAL : _Le_Nom_de_la_64e_fonction". Or la 64e fonction dans l'ordre alphabétique n'est plus la même bien sûr puisque je viens d'en ajouter d'autres... Ainsi, si j'en rajoute 1 : c'est la dernière fonction par ordre alphabétique, si j'en rajoute 2 c'est l'avant dernière, etc.

2) le compilateur GNAT ne semble pas du tout gêné, Implib ne fait pas d'erreur, et le fichier ".lib", regardé sous NotePad contient bien TOUTES les fonctions...(Ainsi que d'ailleurs bien d'autres fonctions qui ne sont pas dans l'interface)

3) Le phénomène se produit en fait quelque soit le nombre de fonctions réellement attendues par le code en C. Je veux dire que si par exemple je déclare moins de fonctions dans la partie 'extern "C" ', c'est quand même toujours la 64e fonction, par odre alphabétique, exportée à l'interface de la DLL qui fait un problème au moment de l'édition de lien avec Borland.

Quelqu'un saurait-il m'éclairer ?
D'avance merci pour votre aide

[Fbartolo]

Je n'ai jamais réalisé une DLL avec autant de fonctions, mais ton analyse semble répondre à la question (64 fonctions max ??).

Le plus simple dans ton cas si il ne te manque pas grand chose, c'est de faire des fonctions paramétrable par familles d'actions pour être en dessous de 64 ou alors 2 DLL.

Donne nous des informations sur la suite de tes travaux, cela peut intéresser du monde.

[vdiem]

Merci pour ta réponse.

J'avoue que 64 fonctions seulement pour une DLL semble être une limite assez faible. En plus cela ressemble à un bug car la limitation est mal gérée : le message d'erreur n'est pas adapté... (il devrait dire quelque choses comme "TOO MANY FUNCTIONS..." et pas "UNRESOLVED EXTERNAL" suivi de la 64e fonction).

Je me suis résolu effectivement à limiter le nombre de fonctions, pour contourner le problème... mais c'est un peu décevant !

Cordialement,
Vincent

[Djob]

juste pour info :

Avec une dll faite sous BCB ce probleme de limite de 64 eme fonction n'intervient pas.
testé avec 76 fonctions..

[vdiem]

76 fonctions ??? C'est interressant !
Comment déclares-tu les fonctions à l'interface ?
Au moyen d'un extern "C" { ... } ou d'une autre manière ?
D'avance merci pour ta réponse ...

Vincent

[Fbartolo]

moins de 64 fonctions, mais pour ma part :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
extern "C" __declspec(dllexport) int CardDetect(bool Debug,
                                                           void (*)(char *Data, int Len));
extern "C" __declspec(dllexport) int CardDriver(bool Debug,
                                                           void (*)(char *Data, int Len));
extern "C" __declspec(dllexport) int CardRead(char *Dirname, int DirnameLen, char *InfoCard, int InfoCardLen, bool Debug,
                                                            void (*)(char *Data, int Len));
extern "C" __declspec(dllexport) int CardUpdate(unsigned long *DateReal, bool Debug,
                                                           void (*)(char *Data, int Len));
extern "C" __declspec(dllexport) int CardApropos(bool Debug,
                                                           void (*)(char *Data, int Len));
 
extern "C" __declspec(dllexport) int CardDowloadDate(unsigned long *DateReal, bool Debug,
                                                            void (*Display)(char *Data, int Len));
 
extern "C" __declspec(dllexport) int CardCalcDate(int *Year, int *Day, unsigned long DatReal, bool Debug,
                                                            void (*Display)(char *Data, int Len));

[Djob]

+1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

extern "C" __declspec(dllexport) __stdcall int etc...

le probleme vient peut être de la Dll ADA ou de implib ..

[vdiem]

Bonjour,

Suite à vos suggestions, j'ai modifié les déclarations des fonctions importées. Au lieu de :
'extern "C" {
float Get_Power(Line);
....

}'.

J'utilise :
extern "C" __declspec(dllexport) float Get_Power(Line);

Ca marche également, mais à la 64e fonction il y toujours le même problème. J'ai également remarqué que ça ne dépend que du nombre de fonctions déclarées dans la DLL et pas au niveau de programme en C.

Toutefois, l'outil IMPDEF permet de voir que TOUTES les fonctions de la DLL écrite en ADA sont bien exportées (y compris après le 64e ...). Donc l'erreur semble provenir :
- soit de l'outil IMPLIB (utilisé avec l'option) -a,
- soit du lieur de Borland...

Après je ne vois pas !
Qu'en pensez-vous ??

[Trap D]

As-tu essayé de faire un chargement dynamique avec LoadModule et GetProcAddress ?

[Fbartolo]

toujours pas de réponse à ta question mais en import c'est plutôt:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

extern "C" __declspec(dllimport) __stdcall int ...

[vdiem]

EUREKA !
Ca y'est j'ai enfin trouvé un contournement satisfaisant :

J'ai gardé le code comme il est, et j'ai simplement modifié la façon de générer le fichier ".lib" et CA MARCHE ! :

avant je créais le fichier .lib à partir de la DLL (appelée "eac") :
* implib -a eac.lib eac.dll

maintenant je crée d'abord un fichier ".def" et ensuite un ".lib" :
* impdef -a eac.def eac.dll
* implib -a eac.lib eac.def

et en procédant comme cela, il n'y a plus d'erreur à la 64e fonction.
Je trouve que ça ressemble à un bug de implib !!

Merci pour votre aide.

Vincent

[Fbartolo]

Bravo; ça c'est de la persévérence; tu pourrais préciser les deux versions de ces outils(impdef et implib)

merci