Discussion :

[Karl Marx]

Bonjour à tous,

Je viens vers vous pour une question concernant l'inclusion de static lib dans une dynamic lib, je précise que je bosse sur windows7, avec codeblocks et TDM GCC 4.8.1/mingw.

Voila, je travail sur 2 projets, l'un qui est un projet de bibliothèque et l'autre qui utilisera la dite bibliothèque.

Le projet de la bibliothèque en lui même nécessite l'inclusion de biblio externe sous format static, jusqu’à la, aucun problème, j'arrive au résultat voulu et à générer ma .dll/.a
Pour inclure ma static lib dans ma .dll, dans le "linker settings" des options de compilation de mon projet, j'ajoute dans le cadre "Other Linker Options" ceci ( en espérant que c'est bien ça qu'il fallait faire ):

Code :

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

1
2
3
4
-Wl,--whole-archive
monChemin/lib1.a
monChemin/lib2.a
-Wl,--no-whole-archive

En revanche, la ou je bloque, c'est pour utiliser la dite bibliothèque dans l'autre projet. Je configure donc mon projet, lui donne le chemin du linker de ma .dll et récupère le fichier header de la dite .dll pour l'utiliser dans le projet.
Le problème c'est lorsque je passe à la phase de compilation, j'ai un jolie petit message d'erreur de ce style :

error: chemin/leHeaderDeMaDll.hpp: No such file or directory ( erreur qui provient du header de la .dll utilisait dans le projet principal )

Le message est clair, pour le compilo, le chemin du fichier inclus dans le header n'est pas bon ( la fameuse static lib que j'ai voulu lié/compilé directement dans ma dll ), ce qui est normal puisque le projet principal n'est pas configuré pour aller chercher de lui même ce qu'a besoin la .dll pour fonctionner puisque normalement, sa devrait être géré directement dans le projet de la bibliothèque.

Ma question est donc :

Que dois-je faire pour résoudre ce problème ? je souhaite que ce qui est géré dans la .dll, le reste, à comprendre, si il y a des bibliothèques static utilisaient dans la .dll, que celle-ci soit directement compilé dedans avec les bon chemins et compagnie et qu'une fois que je l'utilise dans mon projet principal, je n'ai plus à me soucier des différents liens qu'a besoin le projet bibliothèque dynamique.

Ou alors, ce n'est pas possible et je dois aussi configurer mon projet principal pour utiliser la lib static dans ma .dll ou importer le header de la lib static utilisait dans la .dll ?

Merci par avance pour votre aide.

Karl

[Médinoc]

Ici, le problème ne semble pas être spécifiquement un problème de bibliothèques statique/dynamique, mais un problème de gestion des projets et des fichiers d'en-tête.

Pourquoi ne pas simplement ajouter le chemin du répertoire en paramètre du compilo? (-I chemin) (i majuscule)

[Karl Marx]

Oui effectivement, je n'avais pas envisagé cette solution mais du coup, je suis obligé dans mon main project de lui donner tous les fichiers .a and co de la lib static qui est normalement dans la dll ( tous les liens/linker et autre que j'ai du configuré pour le projet de la dll, je dois le reconfigurer quasi à l'identique pour le main project ). Il n'y a aucun moyen de faire autrement ? A comprendre, que dans le main project, je lui donne le header de la .dll + le linker de la .dll ( .a ) mais que je n'ai pas à reconfigurer tous les chemins pour retrouver la lib static compilait et utilisait dans la .dll. ( Que ma dll soit indépendante et embarque déjà tout ce qu'elle a besoin pour fonctionner ).

[Médinoc]

Normalement, le programme principal n'est pas censé avoir besoin du header des libs statiques, à moins que la DLL expose directement des fonctions de celle-ci (déconseillé).

Mais le message d'erreur que tu me montrais était une erreur liée au header de la DLL, pas à celui d'une des libs statiques.

[Karl Marx]

Oui oui, je suis bien d'accord avec toi, je n'ai pas dit le contraire. le message d'erreur vient du header de la .dll qui inclue le header de la lib statitc que j'utilise. ( C'est pour ça que je demandais comment pouvoir gérer ça ).

Par contre quand tu dis ça :

à moins que la DLL expose directement des fonctions de celle-ci (déconseillé).

J'avoue que ce passage m'est un peu obscure, qu'entends-tu par exposé directement des fonctions ? Je veux dire si tu appels une biblio, c'est pour l'utiliser, tu devras forcément appeler des fonctions lui étant propre à un moment ou un autre.

Donc n'ayant pas comprit la subtilité de ta phrase, pourrais-tu éclaircir ma lanterne si ce n'est pas trop demandé ?

Merci par avance.

[Médinoc]

Imagine que tu as LibA qui contient une fonction A(), LibB qui contient une fonction B(), Dll qui contient une fonction D() qui appelle A() et B().

Si Dll expose seulement D(), c'est bon. Si Dll expose aussi A() et B(), c'est moins bon car là tu auras besoin du header de LibA et LibB dans ton programme.

[Karl Marx]

Oki, donc enfaite tu es entrain de me dire, qu'il faut éviter d'utiliser une lib tierce externe et d'appeler des fonctions lui étant propre dans une dll. Du coup l'utilité d'une dynamic lib est plutôt limité pour ce que je voulais en faire.

[Médinoc]

Je n'ai pas dit appeler, j'ai dit EXPOSER.

N'as-tu pas lu mon exemple? Si la fonction de la DLL appelle celles des libs, ce n'est pas un problème.

Le problème, c'est si on cherche à permettre au programme d'appeler directement les fonctions des libs en profitant du fait que la DLL les embarque.

[Karl Marx]

Si si, j'ai bien lu ton exemple.

Mais dans mon programme, je ne fais rien d'autre qu'appeler les fonctions propres à ma .dll, je ne fais rien de plus et encore moins appeler les fonctions directement des libs et donc les exposer dans la dll. J'ai une fonction test() dans la .dll faite par mes soins et dans cette fonction, j'utilise des fonctions de mes libs externe mais dans mon programme principal, je ne fais qu'appeler la fonction test() propre à ma .dll. ( Toute façon, il n'y a que ça de disponible dans la .dll, il n'y a pas de fonction des libs exposé dans la .dll ).

Le seul problème, c'est que comme dans mon programme principal, pour utiliser la .dll, je dois lui donner le header de la .dll et dans ce header que je n'ai pas modifié, il y a l'include des libs externes ( normal puisque quand j'ai compilé la .dll, javais besoin de ces libs puisque j'utilise certaines de leurs fonctions dans les propres fonctions de ma .dlln sans les exposer donc ).

C'est pourquoi depuis mon premier post, je demande quoi faire.

Dois-je modifier le header de la .dll que j'ai inclue dans mon programme pour virer l'include de la lib externe ? Si non, alors quoi faire ? aie-je loupé une manip dans la configuration du projet ?

Mais j'ai bien comprit ton exemple sinon rassures toi et je n'ai jamais utilisé directement les fonctions des libs dans mon programme ou exposer les fonctions des libs dans la dll.

[Karl Marx]

Oki, j'ai donc retiré l'include du header de la .dll dans mon programme et sa fonctionne. En espérant que c'est bien la bonne procédure.

Merci pour ton aide en tout cas.

[Médinoc]

Euh, en fait, qu'est-ce que tu appelles "header de la DLL"?

• Header pour utiliser les fonctions de la DLL?
• Header nécessaire pour compiler la DLL, et qui contient aussi les includes des headers des libs statiques?

Il doit s'agir de deux headers séparés. Seul le premier doit être inclus par le programme, qui n'a pas besoin de connaître les détails internes de la DLL.

[Karl Marx]

Il doit s'agir de deux headers séparés. Seul le premier doit être inclus par le programme, qui n'a pas besoin de connaître les détails internes de la DLL.

C'est exactement ça que j'ai fait hier lorsque j'ai posté pour dire que c'était bon. C'était la donnée qui me manquait pour faire fonctionner tout le système. Encore merci pour ton aide mais c'est vrai que quand on a encore jamais bossé avec des dynamic lib maison, il faut le temps de connaitre.