Version imprimable
Bonjour, je dispose d une librairie créée avec visual, j aimerais linker avec un programme que j ai fait en g++.
J ai cru comprendre qu il faillait faire des modifs au niveau de la librairie (probleme de compatibiltié)
SI quelq u un pouvait m aider. J ai lu qu il fallait utiliser reimp pour créer un fichier .def amis apres je ne comprend pas trop ce que je dois faire...
merci encore
Et en suivant les liens dans les pages que vous avez vous même donnés ??? :
http://outofhanwell.wordpress.com/20...ingw-projects/
bonjour,
j ai effectivement lu ca mais je ne compred pas trop ce qu eje dois faire :
Solution 1
1.Create a definition file using reimp. : OK c est facile...
2.For each stdcall function (formatted as _name@ordinal) add a line name = _name@ordinal, allowing MinGW to map its stdcall naming convention to that of MSVC. : ca se gate un peu... je dois changer quoi la ?
j ai des truc comme ca dans la lib.. (j ai copié que les premieres lignes...)
??0?$omi_IntTable@PEAXVSMABasOmiDefaultAllocator@@@@QEAA@XZ
??0atr_StringBase@@IEAA@AEBV0@@Z
??0cow_String@@QEAA@AEBV0@@Z
??0cow_String@@QEAA@PEBD@Z
??0cow_String@@QEAA@PEBDH@Z
??0stdB_UelmatUserSub@@QEAA@PEAVElementLayout@@PEAN1PEAH22222111111111111111111AEAH2@Z
??
3.Use dlltool to convert the MSVC library into a MinGW library with the new definition. : dlltool va me generer quoi et a partir de quoi?
It worked! To compile the project you must simply:
solution 2
1.Download and install the Qt/Windows package, which includes MinGW... à priori je l ai fait
2.Download reimp and drop it into the MinGW/bin folder. Ok c fait
3.Download the development packages for the third-party libraries and point an environment variable to that location. develpoement packages... je dois faire quoi la?
4.Build the project with the usual qmake/make commands.
merci encore
Là, ça se corse.
Les symboles que vous nous montrez sont des symboles avec le mangling de nom C++ de Visual Studio.
Le mangling C++ n'est pas standardisé.
A l'heure actuelle, votre bibliothèque n'est compatible qu'avec la version de Visual Studio avec lequel elle a été généré.
La garantie avec les autres versions de VS n'est même pas assurée.
Et pire, avec la même version de VS mais avec des options de compilation différentes, c'est des emmerdes sans noms.
En clair, ceux qui on conçu cette bibliothèque sont des branquignols.
Une stratégie à court terme est de faire une bibliothèque de wrapping autour de ce machin, qui elle exportera ses symboles selon les conventions C et non C++.
J arrive a linker avec n importe quelle version de visual...
Sinon
le coup du dlltool... pas possible? il me semblait qu on pouvait modifier le mangling comme ça mais je n ai pas tout compris sur la procédure
merci encore
Changez la configuration du compilateur pour que la lib et le programme utilisateur de la lib, vous allez voir les dégâts. :aie:Citation:
J arrive a linker avec n importe quelle version de visual...
L'export de classes C++, c'est n'import quoi. C'est juste bon à faire des joujoux.
C'est le but de toute la manup avec " line name = _name@ordinal" qui fait des alias entre ne nom à la VS et ne nom à la GNU.Citation:
il me semblait qu on pouvait modifier le mangling
Mais pour cela, il faut utiliser la même convention d'appel. Le mangling est là pour éviter d'appeler les méthodes selon une convention d'appel qui ne convient pas.
Et là, en faisant des exports de classe, c'est pas des conventions _stdcall mais _thiscall, et là, mon gars, c'est du non standard de chez non standard.
Fait une lib qui wrappe en C cette cochonnerie.
Désolé d etre débutant dans le domaine...
Tu pourrais me donner un exemple pour faire ca:
si ma lib C++ contient ??0stdB_UelmatUserSub@@QEAA@PEAVElementLayout@@PEAN1PEAH22222111111111111111111AEAH2@Z comme dans mon exemple, je cree un fonction C avec quoi dedans...
merci et désolé de t embeter....
Ps: si je t envoie mon .def ... ca te dérangerait de faire l interfacage? (je sais j abuse... mais je ne sais pas du tout faire cette étape la...)
Pour revenir à ce point...
>>J arrive a linker avec n importe quelle version de visual...
>>Changez la configuration du compilateur pour que la lib et le programme utilisateur de la lib, vous allez voir les dégâts.
La lib a été créer avec un compilateur/ linker dont j ignore la version. Si je genere un executable avec visual 2006/2010, l exe marche bien... d 'ou mon doute sur le probleme de version de visual.... mais bon le débat est sur g++ ....
Ps: tant qu a compliquer mon probleme.... tu vas aussi me dire ce que tu en penses....
Je résume ma situation:
Fichier toto.c complier en g++
qui fait appel à une librairie azerty.lib linkée par visual
azert.lib fait appel à une autre librairie qsdfg.lib elle aussi linké par visual...
LE wrapper.. il fait le faire que sur azerty.lib??? ou toutes les dépendences (qsdfg.lib)
Je crois que vous sous estimez grandement le travail à effectuer.Citation:
Ps: si je t envoie mon .def ... ca te dérangerait de faire l interfacage?
La commande "undname.exe ??0stdB_UelmatUserSub@@QEAA@PEAVElementLayout@@PEAN1PEAH22222111111111111111111AEAH2@Z" donne :
Il faut donc faire une fonction C qui appel cette méthode et ainsi de suite.Citation:
Undecoration of :- "??0stdB_UelmatUserSub@@QEAA@PEAVElementLayout@@PEAN1PEAH2222
2111111111111111111AEAH2@Z" is :- "public: __cdecl stdB_UelmatUserSub::stdB_UelmatUserSub(class ElementLayout * __ptr64,double * __ptr64,double * __ptr64,int * __ptr64,int * __ptr64,int *__ptr64,int * __ptr64,int * __ptr64,int * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,double * __ptr64,int & __ptr64,int * __ptr64) __ptr64"
Si ces méthodes ne sont pas static, vous devez utiliser un mécanisme de handle opaque pour passer une "référence" à l'objet.
Et il faut faire cela pour toutes les méthodes que votre code g++ devra utilisées, et créer un .h avec toutes ces fonctions C.
Franchement, si la librairie a été pensée pour exporter une API C++ avec des classes, laissez tomber.
Si la lib azerty est bien conçu, que sur azerty.lib. Mais c'est purement théorique car si du C++ et pas du C comme API, c'est trop galère.Citation:
LE wrapper.. il fait le faire que sur azerty.lib??? ou toutes les dépendences (qsdfg.lib) .
Pourquoi ne pas avoir toute la chaine de compilation homogène ?
Si le code est correct, le plus simple est de compiler le tout avec VS.
si un truc est très "orienté objet", la méthode utilisée par COM ("interfaces" - classes abstraites avec méthodes toutes virtuelles déclarées explicitement __stdcall) marche aussi bien sous Visual que MinGW. Ça reste un wrapper, mais ça peut être une alternative au wrapper "flat" à la C.
Bien sûr, aucune de ces deux méthodes ne permet d'utiliser les destructeurs; pour ça, je conseille des classes "inline" qui wrapperaient les appels aux fonctions/méthodes de destruction.
Bé en fait je recupere une API d un logiciel commercial qui a été compilé en visual.... effectivement je viens d installer visual pour qt Creator et ca marche... je vais rester comme ca. Mais je debute dans ces problèmes de link entre compilateur et je pensais que c était plus simple...Citation:
Envoyé par bacelar
merci de votre aide
une derniere question.... si j avais la dll correspondante ca changerait quelque chose?? ou dll et lib... meme combat?
Eh bien... au moins avec la DLL, si tu la charges dans Dependency Walker, tu peux obtenir une liste des noms non-décorés de chaque fonction exportée. Ça peut aider à la création de ton wrapper.
À part ça... même combat.