Comprendre l'option -L de gcc

Bonjour,

J'ai lu pas mal de tutoriel, mais je crois que j'ai un problème de compréhension avec l'option -L de gcc avec Mingw.
Voilà j'ai un main.cpp qui utilise la librairie pthread (pthreadVC2.dll).

Mon projet est dans le dossier Projet
Mon main.cpp dans le dossier Projet/src
et la DLL pthreadVC2.dll est dans le dossier Projet/lib

Voici ma commande de compilation (sous windows avec mingw) depuis le dossier Projet: g++ src/main.cpp -Llib -lpthreadVC2 -o exec.exe

La compilation et l'édition de lien se font sans problème. L'executable exec.exe se trouve dans le dossier Projet. Mais lorsque je le lance il dit que la DLL pthreadVC2.dll manque alors qu'elle se trouve dans le sous-dossier lib et que j'ai rajouté l'ioption -Llib ?

Comment ca se fait qu'il ne va pas chercher dans le sous-dossier lib ?

Merci beacoup
Algernon

Attention, le chemin donné à -L est relative à l'endroit d'où est lancé la commande.

Autrement, ca me semble légitime.
Essaie éventuellement un chemin absolu.

Merci pour votre réponse, j'ai essayé un chemin absolu, mais rien à faire, il ne trouve pas la dll, je vais essayer sous un système unix pour voir.

Algernon

Je ne connaissais pas cette feature que Mingw puisse générer des .lib à partir d'une Dll. :weird:

Alors, si c'est bien le cas, c'est qu'il y a une confusion entre 2 concepts que cette "feature" cache.

Il y a la problématique de l'éditeur de lien : L'option -L de votre ligne de commande est pour lui.
Cela permet à l'éditeur de "coudre" les fonctionnalités des librairies statiques (les .lib) avec l'exécutable.
La feature semble pouvoir extraire l'équivalent d'un fichier .lib depuis un fichier .dll.
Cela génère donc un exécutable statiquement lié à une Dll (oui, c'est un peu contradictoire, mais pas tant que ça).

Il y a la problématique du chargement dynamique de la dll.
Et ici, c'est pas l'éditeur de lien, mais le chargeur de l'OS qui doit récupérer et mapper en mémoire, l'exécutable et l'ensemble des Dll liées "statiquement" à l'exécutable.
Le chargeur n'a pas l'information "aller voir dans /lib" car cette information n'est disponible qu'à la création de l'exécutable. Le chargeur intervient au moment du lancement de l'exécutable, donc bien plus tard.

Il faut donc indique au chargeur de l'OS où aller chercher la ou les dll.

http://msdn.microsoft.com/fr-fr/library/7d83bc18.aspx

Bonjour,

Je comprends le concept de liaison statique d'un dll, ou on va indiquer à quelle dll est liée l'executable et la liaison dynamique qui indique au chargeur d'OS ou se trouve cette fameuse dll.

Cependant, un point sur lequel je doute maintenant: il me semblait que .lib c'est le fichier du code compilé des fonctions de la bibliothèque. Et que .dll c'est la même chose sauf qu'on peut la lier à un executable à l'édition de lien (avantage: pas besoin de recompiler le projet si la librairie est modifiée, on recré la dll uniquement). Mais en vous lisant, j'ai cru comprendre qu'une dll ne peut fonctionner seule ? (sans .lib) Mais la .dll contient bien le code compilé des fonctions de la librairie ?

Algernon

Vous n'êtes pas loin. ;)

un .lib, c'est le code compilé nécessaire à l'édition de lien pour faire son travail de couture.
Quand vous utilisez une Dll, l'éditeur de lien n'a pas besoin du code des fonctions qui sont contenu dans la Dll mais juste du code "glue" qui permet de convertir un appel "local" à l'exécutable en un appel dans la librairie dynamique (via une indirection en passant par des tables dites IAT http://en.wikipedia.org/wiki/Dynamic-link_library).

Si vous utilisez un compilateur comme VS, il génère un fichier .lib en plus du fichier .dll de la Dll, qui ne contient que ce code glue. On parle alors d'un .lib de Dll, qui est donc bien plus petit qu'un vrai .lib de librairie statique.

Comme ce code glue est "facilement" régénérable en regardant dans le fichier .dll ce que la Dll exporte, il est probable que Mingw régénère ce .lib depuis le .dll pour que l'éditeur de lien puisse faire son office.

Le format d'un .dll est bien plus proche du format d'un exécutable que celui d'un .lib. Et quand je dis proche, il est quasi identique à celui d'un exécutable.

Le mécanisme d'import/export entre exécutable et Dll permet d'avoir une totale indépendance entre ceux-ci, du moment que l'interface de la Dll (les symboles qu'elle exporte) ne change pas ou ne fait que s'agrandir.

Bon, sauf si vous échangez des données non-opaque entre l'exécutable et la dll, sinon, il faut qu'ils aient la même C-Runtime.
Bon, sauf si vous utilisez les même threads en exécutable et Dll et qu'il y a des adhérences aux appartments COM.
Bon, sauf si vous fait une optimisation d'appel de fonction en dll via les numéros de symbole et que le .def correspondant est foireux (les MFC, quelles bandes de nouilles).
... (en gros, des dizaines de peaux de bananes).

Merci pour ces précisions, je vais approfondir ces notions de Dll (qui peut être découpée en un .lib et un .dll) avec votre lien sur wikipedia.

Merci
Algernon