Discussion :

[Arwel]

Bonjour,

J'ai récemment installé la dernière version de MinGW (gcc 4.5.0) en téléchargeant et extrayant tout les packages à la main (il faut de la patience )

Pour l'instant, tout se passe plutôt bien, je rencontre cependant un problème avec un simple Hello world :

Lors de l'édition des liens :

warning: auto-importing has been activated without --enable-auto-import specified on the command line.

Pourquoi cela ? Ça ne me le faisait pas avec les précédentes versions.

Si j'ajoute :

-Wl,--enable-auto-import

... aux options de compilation : plus de warning, mais le programme ne se lance pas, parce qu'il manque un dll de la stl

Ca marche en utilisant :

-Wl,--enable-auto-import -static

Mais c'est moche...

Qu'est ce que ça veux dire ? Je dois linker avec la stl à a main maintenant ?

[koala01]

Salut,

Le fait est que MinGW fournit plusieurs version de la bibliothèque standard:

1. une version "dynamique" (sous la forme d'une dll), utilisée par défaut lors de l'édition de liens
2. une version "statique", que l'on peut choisir d'utiliser

L'option --enable-auto-import s'adresse à l'éditeur de liens (ld, disponible au travers du paquetage "binutils") pour lui signaler qu'il doit importer automatiquement les différents symboles depuis les dll qui les exporte.

L'avertissement te signale donc simplement que l'importation automatique des symboles a été utilisée, alors que tu n'avais pas demandé de le faire.

Vient ensuite le fait que le programme ne se lance pas à cause d'une dll manquante:

Lorsqu'un programme a besoin d'une dll, il va chercher d'abord dans le dossier dans lequel il se trouve en espérant la trouver. (cela correspond au dossier "." )

S'il ne la trouve pas, il va chercher dans tous les dossiers connus du système pour contenir des exécutables.

S'il ne trouve pas la dll recherchée, il lui "manque quelque chose" et ne peut donc pas fonctionner, ce qui provoque l'erreur.

La liste de ses dossiers est contenue dans la variable d'environnement PATH.

Classiquement, tu devrais trouver la dll en question dans le dossier <chemin vers MinGW>\bin (ou "chemin vers MinGW" correspond au dossier dans lequel tu as placé le contenu de toutes les archives).

Si tu lances ton programme depuis une invite de commandes, tu peux modifier temporairement et localement (comprend: tant que la ligne de commandes n'est pas fermée, et uniquement pour la ligne de commandes) la variable PATH avec la commande

Code :

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

set PATH=%PATH%;<chemin vers MinGW>\bin

(où chemin vers MinGW correspond, ici encore, au dossier dans lequel tu as placé le contenu des archives)

Si tu veux pouvoir lancer le programme en double cliquant dessus, tu devra, au choix:

• copier la dll (libstdc++-6.dll) dans le dossier dans lequel se trouve ton exécutable
• Ajouter le dossier <chemin vers MinGW>\bin de façon permanente à la variable PATH (panneau de configuration -> système-> modifier les paramètres (accepter l'avertissement) ->onglet "paramètres systèmes avancés"->bouton "variables d'environnement"). Tu pourra décider de la modifier uniquement pour toi (modifier PATH dans la première liste) ou pour tout le monde utilisant l'ordinateur (modifier PATH dans la deuxième liste)
• Copier la dll dans le dossier système connu pour contenir les dll (c:\windows\system32 ou c:\windows\wow32), mais c'est la méthode la moins conseillée

Enfin, il faut savoir que l'option de compilation --enable-auto-import et l'option -static ont quelque chose d'anti-nomique :

--enable-auto-import est, comme je te l'ai fait remarquer, utilisé lorsque tu souhaite... utiliser les bibliothèques externes sous la forme de dll, alors que l'option -static demande, justement, d'utiliser la forme... statique des bibliothèques.

Tu pourrais donc n'utiliser que l'option -static (sans l'option --enable-auto-import), ce qui te permettrait de t'affranchir du besoin de la dll (l'exécutable serait indépendant de la présence ou non de la dll), mais, en contre partie, tu obtiendrais un exécutable plus gros.

[Arwel]

Whaou, merci pour cette belle réponse !

Apparement j'avais pas compris le sens de --enable-auto-import

Ce qui me tracasse c'est qu'avant, je n'avais pas besoin de me soucier de ça.
Je compilais sans options et tout marchais bien.
Est-ce parce que :
J'avais la dll sans le savoir quelque part dans mon PATH et le warning étais mystérieusement étouffé ?

Donc ma vraie question est : pourquoi j'ai ce warning verbeux ?
Sous linux par exemple, un simple g++ helloworld.cpp passe très bien
Et pareil lorsque j'avais encore ma version d'avant de MinGW.

D'autre part, pour redistribuer son application il faut fournir avec la dll de la stl (Dans ./ ou autre) systématiquement ?
Comment se fait-il que je n'en ai jamais entendu parler ?

Dernière question : Comment cela se passe lorsque j'utilise d'autres bibliothèques ? L'option -static s'applique à toutes les options -l ?
Pourtant, certaines bibliothèques (au hasard boost) proposent des versions compilées en statique en plus des versions normales (avec dll). Pour link en static que faut-il utiliser ? -static ou lier a la version statique (suffixée -s) ? Bref, je suis un peu perdu

Question bonus : Dans mon MinGW\bin il n'y a pas cette fameuse dll, est-ce que j'ai loupé quelque chose ?

[koala01]

Whaou, merci pour cette belle réponse !

Apparement j'avais pas compris le sens de --enable-auto-import

Ce qui me tracasse c'est qu'avant, je n'avais pas besoin de me soucier de ça.

Je compilais sans options et tout marchais bien.
Est-ce parce que :
J'avais la dll sans le savoir quelque part dans mon PATH et le warning étais mystérieusement étouffé ?

Les raisons peuvent être nombreuses et vont de l'utilisation d'options de compilation différentes lorsque l'équipe de MinGW a compilé binutils au fait que l'équipe de développement de binutils peut avoir décidé d'inverser la logique par défaut ou, tout simplement, de rajouter l'avertissement entre la version que tu utilisais précédemment et la version actuelle.

Donc ma vraie question est : pourquoi j'ai ce warning verbeux ?
Sous linux par exemple, un simple g++ helloworld.cpp passe très bien

Il faudrait comparer les versions respetives de binutils et de Gcc pour être sur, mais, soit, je viens de te répondre, soit c'est du au fait que les bibliothèques dynamiques sont (peut-être) gérées différemment entre linux et windows

Et pareil lorsque j'avais encore ma version d'avant de MinGW.

cf plus haut

D'autre part, pour redistribuer son application il faut fournir avec la dll de la stl (Dans ./ ou autre) systématiquement ?

Oui, ou décider d'effectuer l'édition de liens avec la version statique de la bibliothèque, avec les avantages et les inconvénients que j'ai cités en vitesse précédemment

Comment se fait-il que je n'en ai jamais entendu parler ?

Sauf erreur, seule la version statique de la stl était utilisée dans les versions précédentes de Gcc (du moins lorsqu'il était compilé pour fonctionner sous windows).

Actuellement, les deux versions (statique et dynamique) sont générées, parfois même en double (32 et 64 bits, si tu utilise le projet mingw-w64), et tu as donc le choix...

C'est ce choix qui se répercute sur les avertissements obtenus ou non

Pour information, tu peux jeter un oeil sur les options de configurations passées lors de la compilation de Gcc en invoquant la commande

Code :

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

gcc -v

Je ne serais pas étonné outre mesure que, avec la version actuelle tu voie apparaitre une option

Code :

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

--enable-shared

mais pas d'option

Code :

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

--disable-static

avec, comme résultat, la création des deux versions, alors que, avec ton ancienne version de gcc, la même commande fasse apparaitre les options soit

Code :

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

--enable-static <...> --disable-shared

soit ne fasse rien apparaitre qui concerne static ou shared (et donc aura provoquer une compilation par défaut de ce point de vue)

Dernière question : Comment cela se passe lorsque j'utilise d'autres bibliothèques ? L'option -static s'applique à toutes les options -l ?
Pourtant, certaines bibliothèques (au hasard boost) proposent des versions compilées en statique en plus des versions normales (avec dll). Pour link en static que faut-il utiliser ? -static ou lier a la version statique (suffixée -s) ? Bref, je suis un peu perdu

Bonne question... faut tester...
[/QUOTE]Question bonus : Dans mon MinGW\bin il n'y a pas cette fameuse dll, est-ce que j'ai loupé quelque chose ?[/QUOTE]Nous parlons bien du dossier dans lequel tu as décompressé l'archive actuelle

Si oui, fais une recherche dans l'ensemble de MinGW basée sur libstdc++-6.dll... Tu devrais la retrouver soit dans bin, soit dans lib, soit dans libexec (ou un sous dossier)

[Arwel]

Super ! Je comprend beaucoup mieux maintenant.

Effectivement mon gcc -v contient --enable-shared et pas --disable-static. C'est tout bon.


Je confirme que je n'ai pas libstdc++-6.dll nulle part dans mon répertoire d'installation de MinGW (C:\MinGW). J'imagine qu'elle devrait se trouver dans l'archive gcc-c++ qu'on trouve ici ? Et ben non :p


Sinon, j'ai essayé de linker avec boost en utilisant cet exemple. Je précise que j'ai compilé cette version (1.43) avec ce compilateur.

boost dynamique (sans les suffixes -s) avec -static :

g++ main.cpp -static -IC:\boost_1_43_0 -LC:\boost_1_43_0\stage\lib -lboost_filesystem-mgw45-1_43 -lboost_system-mgw45-1_43 -o george.exe

Compile sans warning et se lance ... sans avoir besoin des dlls de boost
J'en conclus que -static s'applique à toute les options -l qui suivent et que ld a magiquement fait du static a partir des .a pas statics C'est possible ça ?

Est-ce bien le rôle de l'option -static ?

La page man dit :

Do not link against shared libraries. This is only meaningful on
platforms for which shared libraries are supported. The different
variants of this option are for compatibility with various systems.
You may use this option multiple times on the command line: it
affects library searching for -l options which follow it. This
option also implies --unresolved-symbols=report-all. This option
can be used with -shared. Doing so means that a shared library is
being created but that all of the library's external references
must be resolved by pulling in entries from static libraries.

--> Je voudrais pouvoir lier en static à la stl (comme avant quoi) et en dynamique à boost.

Question bonus : (oui j'aime bien :p) a quoi servent les *.dll.a ? J'ai par exemple libstdc++.dll.a dans C:\MinGW\lib\gcc\mingw32\4.5.0

[koala01]

Super ! Je comprend beaucoup mieux maintenant.

Effectivement mon gcc -v contient --enable-shared et pas --disable-static. C'est tout bon.

Cela indique donc que tout a été configuré de sorte que les différentes bibliothèques soient compilées aussi bien en version statique que dynamique....

Je confirme que je n'ai pas libstdc++-6.dll nulle part dans mon répertoire d'installation de MinGW (C:\MinGW). J'imagine qu'elle devrait se trouver dans l'archive gcc-c++ qu'on trouve ici ? Et ben non :p

So j'en crois les noms des différentes archive, la dll devrait se trouver dans l'archive libstdc++-4.5.0-1-mingw32-dll-6.tar.lzma.

Il semblerait néanmoins que ld soit configuré pour essayer de lier par défaut les différents exécutables avec les versions dynamiques s'il les trouve, ce qui justifie l'avertissement lancé lors de l'édition de liens.

Et comme la bibliothèque d'importation (cf plus loin) est malgré tout présente pour la version dynamique de stdc++, on peut décemment estimer que cela explique l'absence de dll lors du lancement de ton application.

Sinon, j'ai essayé de linker avec boost en utilisant cet exemple. Je précise que j'ai compilé cette version (1.43) avec ce compilateur.

boost dynamique (sans les suffixes -s) avec -static :

Compile sans warning et se lance ... sans avoir besoin des dlls de boost

Il semble donc que tu aies effectué l'édition de liens avec la version statique de boost

J'en conclus que -static s'applique à toute les options -l qui suivent et que ld a magiquement fait du static a partir des .a pas statics C'est possible ça ?

C'est plutôt sans doute du fait que tu dispose des deux version de boost...

Si dans le dossier "lib" de boost, tu trouve des fichier portant seulement l'extension *.a, c'est que tu dispose des versions statiques de boost.

Si tu trouve, dans le même dossier, des fichier aux extension .dll.a, ce sont des bibliothèques d'importation pour les dll qui s'y trouvent également

Le choix de l'une ou de l'autre de ces versions devrait cependant se faire au niveau de l'option -l :

Code :

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

-lboost_filesystem-XX

devrait effectuer l'édition de liens avec la version statique alors que

Code :

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

-lboost_filesystem-XX.dll

devrait effectuer l'édition de liens avec la version dynamique.

Est-ce bien le rôle de l'option -static ?

Normalement, oui

La page man dit :

Do not link against shared libraries. This is only meaningful on
platforms for which shared libraries are supported. The different
variants of this option are for compatibility with various systems.
You may use this option multiple times on the command line: it
affects library searching for -l options which follow it.
This option also implies --unresolved-symbols=report-all. This option
can be used with -shared. Doing so means that a shared library is
being created but that all of the library's external references
must be resolved by pulling in entries from static libraries.

--> Je voudrais pouvoir lier en static à la stl (comme avant quoi) et en dynamique à boost.

Si je traduis correctement ce passage, j'aurais tendance à mettre l'option -static avec son pendant -shared, et la possibilité de spécifier le type de liaison pour chaque (groupe de) bibliothèque, par exemple

Code :

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

g++ fichier.cpp -shared -lboost_filesystem-XX.dll -static -lstdc++-v6 -lautre_bibliotheque_statique -shared -lautre_bibliotheque_dynamique

Question bonus : (oui j'aime bien :p) a quoi servent les *.dll.a ? J'ai par exemple libstdc++.dll.a dans C:\MinGW\lib\gcc\mingw32\4.5.0

C'est ce que l'on appelle une bibliothèque d'importation.

C'est une bibliothèque à utiliser pour permettre à l'éditeur de liens de retrouver les symboles exportés par une dll.

Peut-être le sais tu déjà: une dll exporte un certain nombre de symboles (fonctions et variables)

Sous windows, il est possible de trouver ces symboles dans les fichiers de définitions portant l'extension *.def.

ld n'est cependant pas prévu pour manipuler ces fichiers .def, mais, il est par contre possible de créer une bibliothèque qui, bien que ne présentant pas le code binaire relatifs aux différents symboles, permet à ld de trouver les symboles exportés par les dll.

On appelle cela une "bibliothèque d'importation".

Le problème, c'est qu'il est impossible de donner un nom strictement identique à deux fichiers dans un seul répertoire, que ce soit sous linux ou sous windows.

Si tu décide de proposer une version statique et une version dynamique de la même bibliothèque, tu dois donc trouver un moyen de distinguer la bibliothèque statique de la bibliothèque d'importation nécessaire à l'utilisation de la dll.

Tu pourrais donc décider de garder le même nom de fichier, mais de placer les fichiers relatifs à la version statique dans un fichier et ceux relatifs à la version dynamique dans un autre, mais...

Sur base de l'ordre dans lequel tu précisera les dossiers dans lesquels aller chercher les différentes bibliothèques pour l'édition de liens, l'édition de liens pourrait se faire soit avec la version statique, soit avec la version dynamique, selon le premier fichier trouvé.

La solution est donc, définitivement, de placer les deux fichiers dans le même dossier, en prenant soin de... distinguer clairement les deux versions.

C'est pour cela que tu as un fichier dont l'extension est *.a uniquement (pour la version statique) et un fichier dont l'extension est *.dll.a (pour la version dynamique).

PS: malgré l'apparence d'une réponse complète, j'ai simplifié autant que possible, et j'ai donc laissé quelques points de coté.

L'idée était de te donner un aperçu aussi précis que possible, en évitant malgré tout les aspects les plus complexes.

Cette réponse ne se veut donc absolument pas complète ni tout à fait juste

[Arwel]

Cela indique donc que tout a été configuré de sorte que les différentes bibliothèques soient compilées aussi bien en version statique que dynamique....
So j'en crois les noms des différentes archive, la dll devrait se trouver dans l'archive libstdc++-4.5.0-1-mingw32-dll-6.tar.lzma.

Effectivement, il me manquait cette archive, elle ajoute bien la dll dans MinGW\bin

Il semble donc que tu aies effectué l'édition de liens avec la version statique de boost
C'est plutôt sans doute du fait que tu dispose des deux version de boost...
Si dans le dossier "lib" de boost, tu trouve des fichier portant seulement l'extension *.a, c'est que tu dispose des versions statiques de boost.
Si tu trouve, dans le même dossier, des fichier aux extension .dll.a, ce sont des bibliothèques d'importation pour les dll qui s'y trouvent également

Oui j'ai toutes ces versions. En fait j'ai par exemple pour filesystem (en elevant les versions multithread et debug) :
(1) libboost_filesystem-mgw45-1_43.a
(2) libboost_filesystem-mgw45-1_43.dll
(3) libboost_filesystem-mgw45-1_43.dll.a
(4) libboost_filesystem-mgw45-s-1_43.a
Si je comprends ce que tu dis, 1 est la version statique, 2 et 3 forment la version dynamique (le .dll.a pour l'edition des liens et le .dll pour l'execution), mais alors qu'est ce que 4 ?

Après, c'est peut-être une particularité de boost par ce qu'une autre bibliothèque, par exemple SFML, ne pas tout ca (et je trouve d'ailleurs que c'est plus cohérent). Dans le dossier lib de SFML j'ai :
libXXX-s.a
libXXX.a
XXX.dll

J'en conclus qu'il n'y a pas de convention de nommage, et que chaque bibliothèque fait comme elle veut. Ça me va.

Pour lier statiquement avec la STL et dynamiquement avec d'autre libs il faut donc que je fasse :

Code :

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

g++ main.cpp -static -IC:\boost_1_43_0 -LC:\boost_1_43_0\stage\lib -lboost_filesystem-mgw45-1_43.dll -lboost_system-mgw45-1_43.dll -o george.exe

Il link avec la stl en static (a cause de -static) mais en dynamique avec boost puisque je le lui dit :p

J'en conclu que -static cherche les libs statiques lorsque ld les cherche tout seul. Si on les spécifie avec l'option -lXXX c'est le type (dynamique ou statique) de libXXX.a qui importe.
C'est d'ailleur plus logique comme ca

Cela dit, je vais surement utiliser la version dynamique de la STL, parce que 1Mo le Hello world

L'intérêt des dll, c'est que si deux applications utilisent une bibliothèque, le code n'est présent qu'une fois ? (Dans un dossier du style C:/Windows )
Mais au final sous windows, c'est très mal géré non ? Et au final, chaque application se retrouve a se trimbaler ses dlls parce qu'il y a pas de systeme bien foutu.

[koala01]

Les dll "systèmes"se trouvent classiquement dans c:\windows\system32 (et c:\windows\sysWOW64 si tu as un OS 64bits).

Le principe est, effectivement, de n'avoir qu'une seule fois l'exécutable correspondant, même s'il y a d'autres avantages à avoir des dll (entre autres, le fait de pouvoir charger le code à la demande).

Le problème est que l'utilisation de bibliothèques dynamiques impliquent une dépendance envers la bibliothèque du coté de l'utilisateur, et que l'on ne peut jamais être absolument certain que l'utilisateur aura la bonne version de cette bibliothèque, ni même qu'il l'aura seulement installée.

On en arrive donc à la situation relativement absurde qui consiste à... fournir les dlls des bibliothèques dynamique systématiquement avec l'exécutable