Discussion :

[nutzzz]

Hello tout le monde,

J'ai un soucis avec la génération d'une bibliothèque (statique, mais elle pourrait être dynamique je pense que ce serait pareil). J'utilise Visual Studio 2005.

En général, lorsqu'on écrit un programme utilisant des fonctions externes, on doit lier le programme avec un fichier .lib content l'implémentation des fonctions externes appelées. Exemple : lorsqu'on utilise la lib boost::serialization, on est tenu d'inclure le fichier "boost_serialization_1_33_1_mt.lib". Si par mégarde on oublie d'inclure ce fichier, le linker nous rappelle à l'ordre avec une erreur du genre :
"error LNK1181: cannot open file boost_serialization_1_33_1_mt.lib"

Lorsque je fais la même chose avec une bibliothèque écrite par mes mains, celà se passe autrement. J'oublie d'inclure ma bibliothèque mylib_1_0_4.lib, et le compilateur m'affiche un message du genre :
"error LNK2019: unresolved external symbol 'int thiscall MaFonction(void).."

Pour résumer, avec une librairie compilée par des pros, le linker est capable de dire de quelle biblithèque proviennent les fonctions dont l'implémentation n'a pas été trouvée, par contre, avec une librarie perso, le linker ne sait pas faire le matching et affiche simplement le noms des fonctions non trouvées.

Comment faire pour compiler une lib perso avec la faculté d'associer les fonctions au nom de la librarie ?

Merci beaucoup !

[koala01]

Salut,

D'abord, dans le code, il faut inclure le fichier d'en-tete (typiquement avec un #include "nom_du_fichier.h"), et il faut signaler à l'éditeur de liens qu'il doit lier la bibliothèque donnée (typiquement en fournissant un -inombibliothèque et un -Idossier/ou_trouver_la_bibliotheque) dans la commande de compilation (ou toute autre manoeuvre similaire dépendant de l'EDI utilisée )

L'idée de faire un #include "mabibliotheque.lib" ne m'est vraiment jamais venue (j'espère que ce n'est pas cela que tu fais )

L'astuce, c'est que boost utilise principalement un principe nommé "template" (modèle, si tu préfères en français ) et que l'une des particularités de ces "template" est... que c'est tout à fait générique, et que le code final (aka: qui sera en définitive mis dans l'exécutable) nécessitera d'adapter le code qu'il trouve dans le fichier .lib... à ce qui est réellement sérialisé (selon ton exemple)

S'il ne trouve pas le fichier .lib, cela revient à lui dire "tu dois remplacer tout les blabla par truc et tous les bidule par machin"...sans lui donner la phrase dans laquelle il doit les remplacer

On comprend qu'il rechigne à faire le remplacement en te disant "impossible d'ouvrir le fichier"

Pour ce qui est de tes propres bibliothèques, le problème est différent... Si du moins, tu travailles sans avoir recours aux template :

Pour chaque unité de compilation (1 fichier *.c ou *.cpp + les en-têtes inclues), le compilateur crée une liste des fonctions définies dont l'éditeur de liens va se servir pour faire correspondre les appels à l'adresse à laquelle commence réellement la fonction appelée.

Et, si tu ne dis pas à l'éditeur de lien d'"aller voir dans tel fichier pour trouver les fonctions", bête comme il l'est, il ne pensera pas à le faire de lui-même

Et donc, quand tu compilera ton projet, il trouvera l'appel à une fonction (exemple un a=mafonct() )... mais il ne trouvera pas... l'adresse mémoire vers laquelle il doit faire pointer cet appel...

Et là aussi, on peut comprendre qu'il rechigne à faire son travail

Bref, on a deux causes différentes, qui ont pourtant sensiblement le même effet (l'éditeur de liens n'est pas contents), et qui provoquent chacune un message différent pour te permettre de savoir pourquoi l'éditeur de liens n'est pas content
[PS]
[1]J'ai pris quelques raccourcis faciles pour te permettre de comprendre l'idée... en réalité, c'est sans doute un peu plus compliqué que cela
[2]En français, on parle de bibliothèque, et non de librairie

[D[r]eadLock]

[un peu HS (mais néanmoins intéressant??)] peut-être que boost utilise des pragmas pour forcer le linker à reconnaitre la bibliothèque ??

[nutzzz]

Pas du tout HS du tout, en fait c'est d'ailleurs la solution à mon problème.
Après avoir fouillé autour de cette histoire de pragma, je suis tombé sur ça :

Code :

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

1
2
 
#pragma comment(lib,"libname.lib") //example for the file libname.h

Thank you much !