[dll] inclure une dll

bonjour,
j'e souhaite compiler un pgm qui inclue une dll:
include <pwlib.h>

j'ai la dll: pwlib.dll, mais je ne sais pas ou la mettre pour que mon compilateur sache ou aller la chercher, j'ai aussi tente de paramtrer mon ide (Devc++) au niveau des repertoires d inclusion ou de library,
mais ca ne change rien.

je suppose qu il faut mettre les lib dans un endroit precis, ou bien changer des variables d environnement, car quand on incu avec <> cela n a pas le meme effet que entre ""....

merci de votre aide !

Bart

pwlib.dll doit se mettre soit dans le répértoire contenant l'application, soit dans System32. pwlib.h: tu le mets dans le répértoire include de Dev-C++(Dev-C++\Include\). Note: pas besoin de .a car pwlib.dll est une librabrie dynamique (d'après ce que j'ai compris).

mais est je besoin de pwlib.h alors que j'ai pwlib.dll ??
le pwlib.h ne doit il pas etre dans le .dll?

1- ne pas confondre bibliotheque (library en anglais) et entete (resp header) ! une dll est est une bibliotheque, et non un entete, elle ne peut donc pas etre inclu par une directive #include qui elle est dédiée au entetes...

2- avant d'inclure la lib il faut déjà inclure l'entete de définition des symboles qu'elle contient. la difference entre les <> et les "" est simple le préprocesseur cherche dans les repertoires spécifiées sur la ligne de compilation (option -I) dans le cas des <>, et dans le cas des "" il ajoute le repertoire du source en cours de compilation. Il vaut donc mieux ne jamais utiliser les ""

3- pour inclure ta dll il faut l'ajouter sur la ligne d'edition de liens :
-Lrepertoire -lnom de la lib : pour libtoto.dll mettre toto.

voila, il ne reste plus qu'a toruver ou cela va dans ton IDE, ou dans ton Makefile.

-lnom de la lib: pourquoi? Si la librairie est dynamique, elle n'a rien à faire à la compilation. On la charge avec LoadLibrary(), on récupère un handle sur une fonction avec GetProcAddress(), etc.

Citation:

---

Envoyé par ShootDX

-lnom de la lib: pourquoi? Si la librairie est dynamique, elle n'a rien à faire à la compilation. On la charge avec LoadLibrary(), on récupère un handle sur une fonction avec GetProcAddress(), etc.

---

Ce que tu dis existe : c'est du chargement explicite, dans ce cas là l'entete n'est pas utile, mais c'est lourd s'il y a bcp de fct.

Sinon il y a le chargement implicite, c'est ce que que j'explique, tu indiques la biblio sur la ligne de commande de link et la Dll sera chargée au demarrage de ton application... rien de plus a faire...

L'histoire du -l m'interesse, avant je faisais toujours le chargement avec LoadLibrary(). :oops:

Mais c'est avec quel compilateur ou quel linker? Comment on fait avec Borland Command-line tools? (l'option -l du compilateur permet de modifier les options à passer au linker, mais pas de faire ce que tu dis.)

l'option -l exite sur gcc/g++/ld mais aussi sur la plupart des compilos UNIX

sinon tu doit pouvoir mettre ta Dll simplement sur la ligne de commande avec son chemin complet...

Pour le compilo de Visual c'est le .Lib associé qu'il faut mettre, pas la Dll elle meme...

Gandalf, êtes-vous sûr de ne pas confondre .dll et .a ?

Citation:

---

Envoyé par HRS

Gandalf, êtes-vous sûr de ne pas confondre .dll et .a ?

---

Absolument sur !

en Unix .a et .so sont tres proches...

Et gcc manipule les .dll comme des .so(ou .sl etc.), on aurrait été surpris du contraire, non ?

donc ce que je dis s'applique à gcc (donc à DevC++)...

Visual, lui requiere le .LIB qu'il genere en meme temps que la dll directement sur la ligne de commande...

l'avantage de mettre directement sur la ligne de commande, par rapport à l'option -l c'est que du coup le nom est libre il n'a pas a commencer par lib.