MinGW et la construction de dll

Bonjour,voici ma question plutôt technique sur le linker de MinGW.
J'essaye de générer une dll qui se link avec des librairies statiques (des .a) et dynamiques ( d'autres .dll ). Tout ce joli monde est fait sous MinGW. Les objets de la librairie dynamique que l'on essaie de créer font référence à des objets des librairies statiques, qui ont apparemment besoin de symboles exportés depuis la dll que nous essayons de générer. Bien évidemment, on obtient des erreurs du type "undefined reference", mais le plus étonnant c'est que la compilation de ce truc marche sous linux avec gcc et sous visual studio avec visual studio.

Question pourquoi le linker de MinGW ne fonctionne pas comme celui de linux???
Merci d'avance.

Citation:

---

Envoyé par doommick31

Bonjour,voici ma question plutôt technique sur le linker de MinGW.
J'essaye de générer une dll qui se link avec des librairies statiques (des .a) et dynamiques ( d'autres .dll ). Tout ce joli monde est fait sous MinGW. Les objets de la librairie dynamique que l'on essaie de créer font référence à des objets des librairies statiques, qui ont apparemment besoin de symboles exportés depuis la dll que nous essayons de générer. Bien évidemment, on obtient des erreurs du type "undefined reference", mais le plus étonnant c'est que la compilation de ce truc marche sous linux avec gcc et sous visual studio avec visual studio.

Question pourquoi le linker de MinGW ne fonctionne pas comme celui de linux???
Merci d'avance.

---

J'ai peur de ne pas être suffisamment précis sur la question. Le code que j'essaye de porté sous MinGW a était déjà compiler mainte fois sous une liste de linux( plein de noyau different ) , des redhat, etc... et meme visual pour dire. Comme dit au dessus le composant a des dépendances cycliques bizarres. MinGW possède t'il une particularité sur ce point la ?? Merci d'avance pour votre aide.

Citation:

---

Envoyé par doommick31

J'ai peur de ne pas être suffisamment précis sur la question. Le code que j'essaye de porté sous MinGW a était déjà compiler mainte fois sous une liste de linux( plein de noyau different ) , des redhat, etc... et meme visual pour dire. Comme dit au dessus le composant a des dépendances cycliques bizarres. MinGW possède t'il une particularité sur ce point la ?? Merci d'avance pour votre aide.

---

Salut,

Le linker que MinGW est le même, très exactement (à part les spécificités du format binaire et autres joyeusetés de l'ABI), que celui généralement utilisé avec GCC.

Cependant, il en existe plusieurs versions. Les versions que tu utilises sous Linux n'ont peut-être pas un bug, présent sur ta version pour Windows.

Le linker, ld, est inclus dans le paquet binutils. La dernière version disponible pour Windows, précompilée, est la 2.19.1, la toute dernière version. Utilises-tu bien la même ?

Il est aussi possible que le build du compilateur soit cassé, auquel cas des problèmes peuvent apparaître dans les compilés, ce qui pourrait donner ce genre de résultat. La compilation du linker est peut-être aussi cassée.
Tout ça pour dire qu'une chaîne de compilation est très fragile...

Si les versions correspondent, essaye de déplacer les symboles nécessaires à la lib statique depuis la dynamique vers cette statique, si c'est possible.

Aussi, tu peux essayer de fusionner toutes ces libs, statiques et dynamiques, en une seule et unique, statique ou dynamique, cela réduira fortement les risques de problèmes, si les licences le permettent.

Youpidoup,

ce que tu essayes de faire fonctionne en principe bien sous tous les compilateurs. Tu as une bibliotheque statique (plop.lib, libplop.a sous gcc) qui contient du code pas encore complet, qui lui sera fourni plus tard par celui qui link avec cette lib.

L'exemple le plus connu c'est de fournir dans une bib statique le code de "main" de maniere multi-platforme (WinMain, parsing d'arguments, etc), puis d'appeler une autre fonction main standardisée (qmain, SdlMain, etc)
c'est utilisé, comme indiqué juste au dessus, par Qt et SDL. donc ca marche ^^

il y a un autre type d'erreur, qui empeche le linker de trouver la fonction qui lui manque. Est ce que tu peux poster un exemple ou indiquer ou sont les sources ?

Salut, Merci puor votre aide

J'apporte un peu plus de précision, je suis sous windows xp sp1 et j'utilise mingw 3.4.5 (installé avec l'installeur automatique), la version du linker est bien 2.19.1.

Je viens de faire une grosse lib statique avec toutes mes lib statiques (aucun problème pour un poid de 100mo), je link cette lib statique pour faire ma fameuse dll et j'obtiens la même erreur. Je ne comprends pas pourquoi la statique marche très bien et pas la dynamique.

Je n'ai pas d'exemple sous la main mais pour vous résumer un peu ce que cela donne :
je cherche à faire toto.dll
avec -l(la famille a toto).a -l(encore de la famille a toto).dll

j'obtiens des undefined reference to `_imp___fctdetoto' dans les .a de la famille à toto

en modifiant l'ordre des -l de famille a toto -l(la famille a toto).a .dll je tourne en rond au niveau des erreurs undefined reference.

Citation:

---

Envoyé par doommick31

en modifiant l'ordre des -l de famille a toto -l(la famille a toto).a .dll je tourne en rond au niveau des erreurs undefined reference.

---

Si je m'en souviens bien (on ne rencontre pas si souvent que ça ce genre de cas...), tu mets en premier la lib de base, qui n'a d'autre dépendance que la lib standard. Ensuite, tu mets les dépendances des libs suivantes (et les dépendances des dépendances...), puis les libs suivantes, en t'assurant bien qu'elles ont tout ce qui leur est nécessaire avant. Puis tu ajoutes encore les libs nécessaires, petit à petit.

Cette méthode est très théorique, il faut vraiment savoir ce dont chaque lib a besoin. Si tu as un graphique des dépendances de tes libs, c'est le moment de le sortir. Sinon, tu peux essayer de le faire à l'essai-erreur... (Ce que tu as déjà commencé, il me semble).

Pour cela, ne mets pas toutes les libs d'un coup, mets-les une par une, pour savoir précisément à quel moment ça coince.

En fait c'est typiquement un problème de dépendance cyclique, j'ai pas encore trouver la soluce. (+ de 10 lib)

j'en profite pour mettre un lien sur les option du linker mingw sa peut être utile pour des gens

http://sourceware.org/binutils/docs-...s.html#Options

tu peux mettre une lib deux fois si besoin. je pense que tu devrais "fermer le cercle" de tes dependances en repetant la premiere

Citation:

---

Envoyé par screetch

tu peux mettre une lib deux fois si besoin. je pense que tu devrais "fermer le cercle" de tes dependances en repetant la premiere

---

Désolé, déjà essayer, cela ne marche pas (je tourne en rond au niveau des erreurs je retrouve celle du depart etc.. ).
Alors voilà, j'ai pris un tout autre chemin, j'utilise dlltool pour générer un fichier .def ou se trouve mes symbols, je corrige ensuite le fichier en rajoutant '_imp__' devant chaque export de fonction.
Je génére ensuite un .a que je rajoute au linkage.

Code:

---

1 2 3 4 5

cmd: dlltool -z defile.def objets.o correction du fichier avec '-imp__' dlltool -d defile.def -l libToto.a

---

un lien vers dlltool:
http://www.sourceware.org/binutils/d...s/dlltool.html

J'arrive a avoir ma dll toto;dll mais voila toutes les autres briques que se servent de ma dll ne compile plus.
Du coup j'ai absolument rien résolu.Alors voila de ce que je crois savoir sous linux pour les .so (équivalant dll) tolère au linkage des undefined reference to. Sous visual en créant la fameuse toto.dll et en l'ouvrant avec 'Dependancy Walker' j'ai bien mais fonction exporter avec un E bleu mais les fonction importé sont avec un I rouge.(d'ailleur je ne sais pas la différence entre un I vert et un I rouge sous 'Dependancy Walker', équivaut peut être à trouver pas trouver???)

A aucun moment dans mes autres dll déjà générer je n'ai de fonction décoré avec '_imp__' pour mes import de fonction, d'où ce '_imp__' provient il?

Merci d'avance pour votre aide et j'ai peur être dit des bêtises, n'hésitai pas à me corriger.

Croire que le compilateur mingw c'est comme linux mais sous windows, pas tout ta fait vrai quand même.

Ah, je précise que les fonctions ou j'ai le problème '_imp__ fonction a toto' demandé par la famille .lib .dll à toto sont déclarées avec un __declspec(export). Normal.

Essaye de mettre l'entièreté de tes fichiers objet (.o) dans un seul binaire (.dll / .so) :

Code:

---

gcc -o [fichiers .o]

---

Avec cette méthode, tous les symboles qui n'étaient pas trouvés seront inclus dans le même fichier. Au final, tu auras une lib énorme, mais si ça peut résoudre ton problème...

Citation:

---

Envoyé par dourouc05

Essaye de mettre l'entièreté de tes fichiers objet (.o) dans un seul binaire (.dll / .so) :

Code:

---

gcc -o [fichiers .o]

---

Avec cette méthode, tous les symboles qui n'étaient pas trouvés seront inclus dans le même fichier. Au final, tu auras une lib énorme, mais si ça peut résoudre ton problème...

---

J'ai déjà essayé de faire une énorme librairie statique que je link ensuite j'ai toujours le même problème. Exemlpe :

Code:

---

1 2 3 4 5 6

Making shared library .Win2K_Debug/libToto.dll ... Win2K_Debug/libToto_CommunityActor.a(Toto_Core_i.o): In function `ZN10Toto_Core_iC2Ev': /src/CommunityActor/src/Toto_Core_i.cpp:49: undefined reference to `_imp___ZN8Toto_CoreC2Ev' /src/CommunityActor/src/Toto_Core_i.cpp:50: undefined reference to `_imp___ZN8Toto_CoreD2Ev' etc... avec d'autre lib.a

---

Toto_Core est une classe comprise dans libToto.dll qui a été compiler (Toto_Core.cpp oO)

Citation:

---

Envoyé par screetch

tu peux mettre une lib deux fois si besoin. je pense que tu devrais "fermer le cercle" de tes dependances en repetant la premiere

---

ah oui le cercle de dépendance est sur la librairie que je souhaite, je ne peux pas rajouter une lib qui n'existe pas encore.

Ce code compile sous gcc et visual mais pas sous mingw

sous visual la tolérance au warning level est à 3
sous gcc l'option -O2
mais peut être que cela n'a absolument rien avoir. :bug:

Salut,

Citation:

---

Envoyé par doommick31

Ah, je précise que les fonctions ou j'ai le problème '_imp__ fonction a toto' demandé par la famille .lib .dll à toto sont déclarées avec un __declspec(export). Normal.

---

Rassure moi juste sur une chose:

Tu parle de __declspec(export), mais est-ce bien la valeur utilisée lors de la compilation de la dll et est-elle bien remplacée par __declspec(import) lors de l'utilisation de la dll :question:

Si ce n'est pas le cas, il est plus que temps de prendre les mesures qui s'imposent pour apporter une solution à ce point.

Les deux possibilités qui te sont données sont:
créer deux jeux de fichier d'en-tête:

• l'un à utiliser lors de la compilation de la dll et dans lequel tu utilisera __declspec(export)
• L'autre à utiliser lors de l'utilisation de la dll et dans lequel tu utilisera __declspec(import).

Mais c'est le choix sans doute le moins opportun, car il implique le fait de devoir mettre de manière systématique les deux fichiers d'en-tête à jour lors de chaque modification (ce qui est source d'erreurs et d'oublis)

Le second consiste à utiliser une directive préprocesseur permettant de déterminer si tu es en phase de compilation ou en phase d'utilisation de ta dll...
Elle serait proche de

Code:

---

1 2 3 4 5

#if defined(BUILD_DLL) #define DLL_ABI __declspec(export) #else #define DLL_ABI __declspec(import) #endif

---

et présente (par inclusion) dans chaque fichier faisant utilisant __declspec.

Il faudrait ensuite remplacer dans l'ensemble des fichiers __declspec(export) par DLL_ABI

Il "suffira" ensuite d'ajouter une option -DBUILD_DLL lors de la compilation de la dll ;)

NOTA: BUILD_DLL et DLL_ABI peuvent prendre n'importe quel nom de ton choix, pour autant qu'il évitent tout risque de confusion lors de l'utilisation / la compilation d'autres bibliothèques :D

Tout d'abord merci de ta réponse, je vais m'efforcer d'être le plus clair possible parce que le problème auquel je suis rencontré n'est pas banal.

Je te rassure, je suis très exactement dans le second cas que tu cite :

Citation:

---

Le second consiste à utiliser une directive préprocesseur permettant de déterminer si tu es en phase de compilation ou en phase d'utilisation de ta dll...
Elle serait proche de
Code :

#if defined(BUILD_DLL)
#define DLL_ABI __declspec(export)
#else
#define DLL_ABI __declspec(import)
#endif

et présente (par inclusion) dans chaque fichier faisant utilisant __declspec.

Il faudrait ensuite remplacer dans l'ensemble des fichiers __declspec(export) par DLL_ABI

Il "suffira" ensuite d'ajouter une option -DBUILD_DLL lors de la compilation de la dll

---

J'ai bien ajouter mon option -DBUILD_DLL_A_TOTO pour passer dans le define #define BUILD_DLL_A_TOTO __declspec(export)

avec BUILD_DLL_A_TOTO cad __declspec(export) definie devant la classe TotoCore dans le hpp.
J'ai aussi essayé de placer BUILD_DLL_A_TOTO devant chaque méthode public des-fois que. Je me retrouve toujours avec les mêmes erreurs :

Citation:

---

mingw32-make prod
Making shared library .Win2K_Debug/libToto.dll ...
libToto_CommunityActor.a(Toto_Core_i.o): In function `ZN10Toto_Core_iC2Ev':
/Toto_Core_i.cpp:49: undefined reference to `_imp___ZN8Toto_CoreC2Ev'
Toto_Core_i.cpp:50: undefined reference to `_imp___ZN8Toto_CoreD2Ev'
libToto_CommunityActor.a(Toto_Core_i.o): In function `ZN10Toto_Core_iC1Ev':
etc...

---

Je rappelle que je fait un portage sous mingw d'u ncode qui compile link et fonctionne sous linux (plein), et visual. Je n'ai absolument pas toucher au source, il est tout vert sous svn.
Pour ma dll, je souhaite exporter ces fonctions, c'est lors du linkage de cette dll que j'ai des undefined reference to '_imp__ZN8fonctiondelaenquestiondll' dans des fonctions situé dans d'autres librairies.a.

Je pense qu'il y a une dépendance cyclique avec la même dll. En vérifiant les symbole des fonctions exporté, avec dlltool je n'ai pas '_imp__' devant mes fonctions. Normal parce que je suis en export, mais le linker veut des _imp__ .

Pour information en compilant en passant par #define DLL_ABI __declspec(import) je ne le souhaite pas mais pour le fun j'ai droit à un magnifique :

Citation:

---

Toto_Core.cpp:617: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
mingw32-make: *** [.Win2K_Debug/Toto_Core.o] Error 1

---

Ton post re-situe bien mon problème de linkage. Si vous avez des questions n'hésitez pas ?

Citation:

---

Envoyé par doommick31

Je te rassure, je suis très exactement dans le second cas que tu cite :

---

C'est déjà pas mal, mais c'était la première chose à vérifier :D

Citation:

---

J'ai bien ajouter mon option -DBUILD_DLL_A_TOTO pour passer dans le define #define BUILD_DLL_A_TOTO __declspec(export)

avec BUILD_DLL_A_TOTO cad __declspec(export) definie devant la classe TotoCore dans le hpp.

---

Attention, BUILD_DLL_A_TOTO ne doit être défini que sous la forme d'une option de compilation, sous peine d'avoir __declspec(export) au lieu de __declspec(import) lors de l'utilisation...

Cela signifie que la commande à lancer pour compiler un fichier est
gcc -c fichier.cpp -DBUILD_A_TOTO
(ou que tu as une variable dans ton makefile qui constient -DBUILD_A_TOTO et qui est rajoutée à la commande de compilation)

Citation:

---

J'ai aussi essayé de placer BUILD_DLL_A_TOTO devant chaque méthode public des-fois que. Je me retrouve toujours avec les mêmes erreurs :

---

Cela ne sert à rien et est même dangereux:

BUILD_A_TOTO n'est défini que pour la compilation de la dll et est absolument inconnu au bataillon lors de son utilisation...

Tu risque donc d'avoir une erreur du compilateur te disant que BUILD_DLL_A_TOTO est un symbole indéfini lorsque tu tentera de compiler l'application qui utilise la dll ;)

Citation:

---

Je rappelle que je fait un portage sous mingw d'u ncode qui compile link et fonctionne sous linux (plein), et visual. Je n'ai absolument pas toucher au source, il est tout vert sous svn.

---

On va essayer de travailler dans l'ordre de manière claire et précise:

Tu essaye de compiler une application qui utilise la dll ou la dll elle-même :question:

Si tu essaye de compiler la dll:

• dispose tu (ne serait-ce que par compilation "perso") des bibliothèques statiques nécessaires :question:
• les bibliothèques statiques ont-elles bien été compilées avec le même compilateur de la même version et avec les mêmes options de compilation que la dll que tu essaye de compiler :question:
• es-tu sur des chemins d'accès menant aux biblilothèques statiques :question:

Si tu essaye de compiler une application:
dispose tu d'une version des bibliothèques statique correspondantes pour ton compilateur :question:

• La bibliothèque d'importation a-t-elle été créée avec le même compilateur (éventuellement reimp + dlltools pour convertir le XXX.lib en libXXX.a adapté à ton compilateur) :question:
• es-tu sur que la bibliothèque d'importation est bien accessible depuis l'un des chemins d'accès aux bibliothèques définis pour le projet :question:
• es-tu sur que le noms de bibliothèques correspond :question: (un petit numéro de version qui s'intercale dans le nom de la bibliothèque peut mener à des catastrophes :D)

je crois que la DLL elle meme cherche a résoudre ses propres liens avec un declspec(dllimport) au lieu de declspec(dllexport)
as tu des warnings sous visual studio ?

j'obtiens la même erreur avec le code suivant :

main.cc : dit que doPrint est "dllimport"

Code:

---

1 2 3 4 5 6 7

__declspec(dllimport) void doPrint();   int main(int argc, const char* argv[]) { doPrint(); return 0; }

---

test.cc

Code:

---

1 2 3 4 5 6

#include <cstdio>   void doPrint() { printf("Hello, world!\n"); }

---

alors que l'on a dit a main.cc que "doPrint" sera importée, on la fournit directement dans le code, et donc le résultat est *PAF* erreur de link

Re-bonjour

Oui j'ai bien -DBUILD_A_TOTO dans ma ligne de compilation, sous eclipse il est à 1 ( je l'ai ajouté dans mon makefile).

Dans l'ordre :

J'essaye de compiler une .dll sous mingw. Cette dll utilise des .a et des .dll qui eux mêmes on était compiler
par mes soins sous MinGW (dernière version sur le net installer avec installeur automatique).

Citation:

---

Je rappelle que je fait un portage sous mingw d'un code qui compile link et fonctionne sous linux (plein de version du noyau), et visual. Je n'ai absolument pas toucher au source, il est tout vert sous svn.

---

Je ne fait aucun mélange, je précise juste que je faisait un portage.

Citation:

---

* dispose tu (ne serait-ce que par compilation "perso") des bibliothèques statiques nécessaires

---

Les bibliothèques statiques nécessaires pour compiler ma dll, je l'ai possède toutes et elles ont toutes était compilées.

Citation:

---

* les bibliothèques statiques ont-elles bien été compilées avec le même compilateur de la même version et avec les mêmes options de compilation que la dll que tu essaye de compiler

---

Je vérifie, ok tout est pareil.

Citation:

---

* es-tu sur des chemins d'accès menant aux bibliothèques statiques

---

Vérifier ok pour eux tous présent

Citation:

---

je crois que la DLL elle même cherche a résoudre ses propres liens avec un declspec(dllimport) au lieu de declspec(dllexport)
as tu des warnings sous visual studio ?

---

OUI, sous Visual, j'obtiens ma dll mais avec quelque warning qui d'ailleurs ne sont pas sans me rappeler les undefined reference que j'ai sous MinGW. Il y a juste la décoration qui change.

Citation:

---

Generating Code...
Linking...
Creating library Debug/TOTO.lib and object Debug/TOTO.exp
LINK : warning LNK4049: locally defined symbol ""public: virtual __thiscall TOTO_Core::~TOTO_Core(void)" (??1TOTO_Core@@UAE@XZ)" imported
LINK : warning LNK4049: locally defined symbol ""public: __thiscall TOTO_Core::TOTO_Core(void)" (??0TOTO_Core@@QAE@XZ)" imported
LINK : warning LNK4049: locally defined symbol ""public: class TOTO_Clock * __thiscall TOTO_Core::getClock(void)" (?getClock@TOTO_Core@@QAEPAVTOTO_Clock@@XZ)" imported
LINK : warning LNK4049: locally defined symbol ""public: static class TOTO_Core * __cdecl TOTO_Core::getSingleton(void)" (?getSingleton@TOTO_Core@@SAPAV1@XZ)" imported
LINK : warning LNK4049: locally defined symbol ""public: class TOTO_TimeMgr * __thiscall TOTO_Core::getTimeMgr(void)" (?getTimeMgr@TOTO_Core@@QAEPAVTOTO_TimeMgr@@XZ)" imported
LINK : warning LNK4049: locally defined symbol ""public: class TOTO_SysDataMgr * __thiscall TOTO_Core::getSystemDataMgr(void)" (?getSystemDataMgr@TOTO_Core@@QAEPAVTOTO_SysDataMgr@@XZ)" imported
LINK : warning LNK4049: locally defined symbol ""public: enum TOTO_FctStatus __thiscall TOTO_Core::receivePendingData(int *,int *,unsigned int const * *)" (?receivePendingData@TOTO_Core@@QAE?AW4TOTO_FctStatus@@PAH0PAPBI@Z)" imported
LINK : warning LNK4049: locally defined symbol ""public: enum TOTO_FctStatus __thiscall TOTO_Core::unlockDataAccess(void)" (?unlockDataAccess@TOTO_Core@@QAE?AW4TOTO_FctStatus@@XZ)" imported
LINK : warning LNK4049: locally defined symbol ""public: enum TOTO_FctStatus __thiscall TOTO_Core::receiveFirstData(int *,int *,unsigned int const * *)" (?receiveFirstData@TOTO_Core@@QAE?AW4TOTO_FctStatus@@PAH0PAPBI@Z)" imported
LINK : warning LNK4049: locally defined symbol ""public: enum TOTO_FctStatus __thiscall TOTO_Core::lockDataAccess(void)" (?lockDataAccess@TOTO_Core@@QAE?AW4TOTO_FctStatus@@XZ)" imported
LINK : warning LNK4049: locally defined symbol ""public: enum TOTO_FctStatus __thiscall TOTO_Core::importData(int)" (?importData@TOTO_Core@@QAE?AW4TOTO_FctStatus@@H@Z)" imported
LINK : warning LNK4049: locally defined symbol ""public: enum TOTO_FctStatus __thiscall TOTO_Core::exportAndSend(int)" (?exportAndSend@TOTO_Core@@QAE?AW4TOTO_FctStatus@@H@Z)" imported
LINK : warning LNK4049: locally defined symbol ""public: enum TOTO_FctStatus __thiscall TOTO_Core::send(int)" (?send@TOTO_Core@@QAE?AW4TOTO_FctStatus@@H@Z)" imported
Creating browse info file...

---

Est ce grave?

Citation:

---

Envoyé par screetch

je crois que la DLL elle meme cherche a résoudre ses propres liens avec un declspec(dllimport) au lieu de declspec(dllexport)
as tu des warnings sous visual studio ?

---

D'après mes warnings sous visual je pense que c'est le problème auquel je suis confronté, mais comment expliquer les différence entre GCC, visual, MinGW.

- Visual te donne des warning
- GCC te donne des erreurs
- Ces directives de compilation ne sont utilisées que sous windows, sous linux tout est exporté par defaut (bien que le systeme de declspec existe sous linux aussi) donc aucune erreur

mais, de toute évidence, lorsque tu construits la DLL, __declspec(dllimport) est utilisé.

Pourtant je mes bien mon -DBUILD_A_TOTO qui me permets de passer dans __declspec(dllexport). J'ai bien vérifier en le forçant tout seul

#define BUILD_A_TOTO __declspec(dllexport)

J'ai découvert en cherchant un peu sur le net que par défaut sur mingw/cygwin auto import est activé par défaut :
source :
http://www.redhat.com/docs/manuals/e...ker/win32.html

Citation:

---

The standard Windows dll format supports data imports from dlls only by adding special decorations (dllimport/dllexport), which let the compiler produce specific assembler instructions to deal with this issue. This increases the effort necessary to port existing Un*x code to these platforms, especially for large c++ libraries and applications. The auto-import feature, which was initially provided by Paul Sokolovsky, allows one to omit the decorations to archieve a behavior that conforms to that on POSIX/Un*x platforms. This feature is enabled with the -enable-auto-import command-line option, although it is enabled by default on cygwin/mingw. The -enable-auto-import option itself now serves mainly to suppress any warnings that are ordinarily emitted when linked objects trigger the feature's use.

---

J'essaye d'utilisé l'option du linker --disable-auto-import
source :
http://sourceware.org/binutils/docs-...s.html#Options

Citation:

---

--disable-auto-import
Do not attempt to do sophisticated linking of _symbol to __imp__symbol for DATA imports from DLLs. [This option is specific to the i386 PE targeted port of the linker]

---

Mais cela ne fonctionne pas.

C'est bon je pense avoir résolu le truc alors il faut absolument que les commandes de compilation des lib statique et dynamique soit rigoureusement identique au niveau des options de compilation. Voilà tout sa pour ça.

En tout cas merci pour ces bons conseils.

Citation:

---

* les bibliothèques statiques ont-elles bien été compilées avec le même compilateur de la même version et avec les mêmes options de compilation que la dll que tu essaye de compiler

---