Discussion :

[gege2061]

Bonjour,

Je suis en train de créer un système de plugin pour un logiciel, j'utilise donc, sous windows, des dll.

Bizarrement lors de la compilation de celles-ci, gcc passe par l'étape d'édition. Bien évidement, j'obtiens des erreurs au niveau des fonctions de l'API de mon application puisque je fourni uniquement un fichier d'interface (les fichiers .h pour résumés).

J'utilise waf comme système de compilation, voici la commande générée :

Code :

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

gcc.exe default/plugins/todo/todo_1.o -o default/plugins/todo/libtodo.dll -shared -Lc:/codeblocks/mingw/lib -Wl,-Bdynamic -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgtksourceview-2.0

Sous linux j'ai sensiblement la même chose (ça fonctionne comme je le souhaite), excepté les options suivantes en plus :

Code :

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

-Wl,-h,libtodo.so.0 -Wl,--export-dynamic

J'ai loupé une étape, ou l'édition des liens des DLL n'est pas dynamique sous Windows ?

[Médinoc]

J'ai du mal à comprendre ce que tu dis.

C'est à la compilation de l'EXE que tu as des erreurs ?
Comment cherches-tu à utiliser la DLL ? Si c'est un système de plugin, le __declspec(dllimport) n'est pas fait pour toi: Tu dois utiliser LoadLibrary(), GetProcAddress() et des pointeurs de fonction...

[gege2061]

C'est à la compilation de l'EXE que tu as des erreurs ?

Non, le coeur de l'application compile sans soucis. Ce sont les dll qui font office de plugins.

Comment cherches-tu à utiliser la DLL ? Si c'est un système de plugin, le __declspec(dllimport) n'est pas fait pour toi: Tu dois utiliser LoadLibrary(), GetProcAddress() et des pointeurs de fonction...

Je passe par la glib qui utilise bien LoadLibrary et GetProcAddress.

Mon problème n'est pas lors de l'utilisation du plugin mais lors de sa compilation : pourquoi gcc effectue l'étape d'édition des liens, alors qu'ils sont censés être résolus lors de l'exécution ?

[edit]Je n'ai pas ce genre de problème lorsque je créée une bibliothèque statique [/edit]

[Médinoc]

Seules les libs statiques n'ont pas d'édition des liens: Elles ont seulement un rassemblement des morceaux.

Les libs dynamiques sont des fichiers exécutables presque comme les autres: Ils ont des "ressources", et utilisent eux-mêmes des libs statiques. Il y a donc une édition de liens pour les DLLs. Si tu veux faire deux DLLs qui s'utilisent entre elles, il faut "tricher" : http://msdn.microsoft.com/en-us/libr...x6(VS.80).aspx

Une DLL n'est pas supposée faire appel à des fonctions de l'EXE qui les utilise, à part en callback.
Une lib statique non plus, d'ailleurs, sauf dans le cas de libs contenant leur propre "main"...

[gege2061]

Ok, ça dépasse ma logique mais si ça a été décidé ainsi, c'est qu'il doit y avoir une raison. Je vais donc séparer l'api du programme principal.

Merci pour ton aide