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