utilisation de dll avec diverses compilateurs

**Thylia** · 16/10/2002, 23h44

Salut,

Je développe actuellement avec C++Builder 6 et je suis confronté à un problème : je voudrais utiliser des dll que mon collègue compile avec le compilateur d'IBM, mais lorsque je fait la bibliothèque d'importation (.LIB) avec l'utilitaire IMPLIB, mon compilateur lors du link n'arrive pas à faire trouver la fonction dans le LIB.
A cela, j'ai trouvé un début de solution qui est de déclarer les fonctions en __stdcall. Mais cette solution n'est pas envisageable avec des fonctions C++ surchargées, le compilateur nous jette.
Alors, ce que je vous demande c'est s'il faut mettre un autre type de conventions devant les fonctions ou s'il y a d'autres solutions.

Merci encore d'avance.

**JEG** · 17/10/2002, 00h46

J'ai le meme probleme avec les dll faites sous visual. C'est comme si implib, m'avait viré le corps de la fonction.

**LFE** · 17/10/2002, 09h58

Jeg, il me semble que c'est le probleme dont on a discute l'autre jour.

Thylia, si tu veux, et que la DLL n'est pas trop grosse, envoie la moi avec le fichier .h.

ou une petite DLL toute simple, avec juste une fonction ou 2

Comme ca on sera 3 a pouvoir regarder au probleme ... et ca me permettra de continuer mon tut sur les DLL

**haypo** · 17/10/2002, 13h14

Le plus simple est de recompiler le DLL, non ?

Ok, c'est un peu bourrin, mais des fois on a pas le choix. J'ai essayé de compiler un hello world avec GTK+ 2.0 : après 10 IMPLIB, et pas mal de bidouille, je suis arrivé à terminer la compilation et la liaison ... "Internal GTK Error" : "... or your compiler is not supported" :-/ En gros faudrait que je recompile GTK+2.0 avec BCB6 ... mais je vais devoir modifier un gros bout de code pour ça. J'ai abadonné.

@+ Haypo

**JEG** · 17/10/2002, 13h49

effectivement, mais bon l'interet de la dll est perdu...... et des fois on n'a pas le code source de la dll

**Gandalf** · 17/10/2002, 17h26

Il n'y a pas de solutions...

Les surcharges de fonction sont gérées par les compilo par ce que l'on appelle les décorations, c'est à comme si la fonction toto(int) etait appellée toto_int et la fonction toto(double) toto_double. Evidement ces decorations sont codées, et les compilateurs ne decorent pas tous de la meme maniere...

donc pour pouvoir importer un fontion d'une DLL tu dois indiquer à ton compilo de ne pas la décorer -> stdcall ou extern "C"...

Conséquence, la surcharge est impossible...

Un workaround ? faire la decoration toi-meme

toto_for_int (int);
toto_for_double(double);

C'est pas génial, je sais...

**Thylia** · 17/10/2002, 23h31

La solution de recompiler est impossible car tu vois essayer de compiler les dll avec par exemple Borland, ce serait comme essayer de recompiler un prog VC++ (avec Mfc et toute les autres choses de VC++) avec Gcc.

La solution de refaire les dll avec des fonctions qui s'appelle par exemple :
toto_for_int (int);
toto_for_double(double);
n'a pas d'intérêt car on perte tout les bienfait du C++.

On a pensé avec mon collègue qu'il serait intéressant de fouiller vers la numérotation ordinale car elle est unique. Mais, on a pas le temps de si plonger, on est à la bourre pour un projet et donc si vous pouvez voir ou me dire quelque chose dans cette direction, je vous remercie d'avance.

**Gandalf** · 18/10/2002, 11h43

Pour utiliser la numerotation ordinale il me semble que tu dois charger la DLL explicitement (LoadLibrary) et obtenir l'adresse de chaque methode par un GetProcAdress...

Du coup tu te retrouve avec des pointeurs de fct...

Pour fixer les ordinaux dans la DLL tu dois faire un .DEF...

**LFE** · 18/10/2002, 13h11

Je suis en train de faire l'essai avec fmod, voir comment cela marche et jouer avec leur DLL....
je vous tiens au courant

**Thylia** · 22/10/2002, 11h57

Envoyé par Gandalf

Pour utiliser la numerotation ordinale il me semble que tu dois charger la DLL explicitement (LoadLibrary) et obtenir l'adresse de chaque methode par un GetProcAdress...

Du coup tu te retrouve avec des pointeurs de fct...

Pour fixer les ordinaux dans la DLL tu dois faire un .DEF...

Je vois pas pourquoi, il faut faire un fichier .DEF, il suffit juste de savoir le numéro ordinal.

**Gandalf** · 22/10/2002, 15h02

Certes tu peux regarder le numero a l'aide d'outils tel Dependency Walker... Mais qui te garentie que ce numéro ne changera à l'occasion d'une nouvelle compilation de la DLL ?

**HRS** · 22/10/2002, 17h23

moi qui croyait naïvement que l'intérêt de la dll est qu'elle est indépendante du langage qui la crée et indépendante du langage qui
l'utilise

concernant les fonctions surchargées. quand on regarde les API windows,
elles sont pratiquement toutes doublées avec un suffixe A ou W selon
que les caractères font 8 bits ou 16 bits. cela vient surement du fait que le
langage C en permet pas la surcharge, donc les dll non plus.

**LeGreg** · 22/10/2002, 20h08

la dll est effectivement independante du langage,
seul probleme elle n'inclue pas de notion "d'objet"
et de classe
c'est un peu comme pour les fichiers .obj du C que l'on
utilise aussi en C++,
Conclusion les compilateurs sont obliges de feinter
pour permettre d'utiliser des classes a travers des dlls
(ou des .obj) et ca se fait via la decoration de nom (name
mangling) moyen que l'on a trouve de coder des methodes
de classe et la surcharge
dans des fichiers objet d'un langage qui ne supporte
que les fonctions globales et non surchargees...

C'est un bete archaisme, mais d'un autre cote la dll
a ete pense pour un environnement multi langage mais pas objet
pour ca il y a COM, CORBA, COM+, .NET etc..
(qui peuvent utiliser des dlls mais qui deguisent les objets de maniere
standardisee).

LeGreg

**Thylia** · 22/10/2002, 20h27

Donc est ce que la conclusion à en tirer est qu'il est totalement impossible d'utiliser les dll C++ avec différents compilateur ?

**LeGreg** · 22/10/2002, 21h31

si tu restes sous windows
je regarderais du cote de COM.

C'est independant du langage et les objets sont
enregistres aupres du systeme, il y a donc un
petit surcout mais ca peut-etre interessant
pour faire du code objet cross-langage.

LeGreg

**Chal** · 25/10/2002, 23h04

Pour ajouter ma pierre à l'édifice :

Effectivement l'utilisation d'un LIB direct est imposible en raison de différence de codage

Par contre, on peut effectivement utiliser un .DEF mais c'est lourd dingue
voir par exemple l'URL suivante pour la méthode :
http://www.xploiter.com/programming/c/borland/3173.html

La technique la plus simple et qui fonctionne toujours (ou presque...) est d'utiliser des méthodes C (extern "C")

Dans le cas d'une classe, voici la technique (je l'ai utilisé pour faire un lien entre une classe C++ et une classe JAVA via l'interface JNI qui est en C)

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
class MaClass
{
  void MaMethode( long param1, long param2 );
}
 
//-- Méthode qui seront exporté
long init_MaClass( void )
{// Construction
  return ( (long)new MaClass() );
};
 
void termine_MaClass( long handle )
{// Destruction
  MaClass *cl= (MaClass *)handle;
  delete cl;
};
 
void MaClass_MaMethode( long handle, long param1, long param2 );
{// appel de méthode
  MaClass *cl= (MaClass *)handle;
  cl->MaMethode( param1, param2 );
}
 
// utilisation dans l'autre DLL...
long handle= init_MaClass();
 
MaClass_MaMethode( handle, 5000, 2 );
 
termine_MaClass( handle );

Effectivement, c'est un peu long à coder... mais cela marche...

Attention, au allocation mémoire ! Une donnée allouée par une DLL d'un compilateur doit être déssallouer par la même DLL

**Thylia** · 26/10/2002, 01h24

Oui, je sais dejà que c'est possible avec extern "C" ou stdcall, mais pour moi le but, est de conserver les dll's en l'état sans refaire le code (100 000 lignes et + )
Mais merci quand même pour le lien.

**PascalV.** · 26/10/2002, 11h09

Bonjour,

Sinon ce que tu peux faire, c'est charger la DLL manuellement.
Tu fais:

HMODULE handle = LoadLibrary("nom de la dll");
void* adresse de la fct = GetProcAddress(handle, "Nom de la fonction");

Je l'ai fait avec Delphi et VC.
Je ne suis pas sur du LoadLibrary sous Borland mais je pense
que ca existe.

Bonne journée.
Pascal.

**LeGreg** · 28/10/2002, 04h54

Envoyé par Thylia

Oui, je sais dejà que c'est possible avec extern "C" ou stdcall, mais pour moi le but, est de conserver les dll's en l'état sans refaire le code (100 000 lignes et + )
Mais merci quand même pour le lien.

euh, tu sais moi j'ai du assurer le passage de nos dlls de VC6 a VC7
conclusion, j'ai passe trois semaines a reecrire le code des interfaces pour que ca compile sous VC6 et que les dlls puissent etre linkees sous VC7, tout en s'assurant que mes modifs n'auraient aucun impact sur nos autres plateformes, ni pour les utilisateurs restes a VC6.. heureusement on n'est pas sense supporter les compilateurs Borland... et les autres plateformes(non windows) n'ont pas (trop) de soucis de compatibilite entre les differentes versions de compilateurs..

Mais c'etait un passage oblige a partir du moment ou certains de nos clients allaient passer sous VC7.

LeGreg