Créer une bibliothèque statique composée d'autres bibliothèques statiques

Bonsoir,
Après avoir fais plusieurs jeux en OpenGL avec d'autres bibliothèque, je me rend compte que certaines parties sont répétitifs et donc j'aimerais faire mon propre petit moteur sous forme d'une bibliothèque appart. Le but est donc de ne plus avoir à link plusieurs libs mais une seul qui regroupe l'ensemble. Cette lib s'appelle "Axion" et est composé de: -SFML -Boost -Glew -GLM. Je précise que cette bibliothèque est à usage personnel pour éviter des problèmes avec les licence ou autre.
Pour m'y prendre, j'ai deux projets:
-AxionLib: dans lequel je crée la bibliothèque (include, srx et lib)
-Projet Test: dans lequel je teste la bibliothèque.

J'inclue l'ensemble des mes bibliothèques dans Axion, le tout en statique pour éviter des problèmes avec les .dll. La compilation fonctionne et la taille du .lib est important (18Mo) donc j'en déduis que cela à fonctionné vu la taille de l'ensemble des libs.
En revanche, lorsque je link Axion dans le projet Test (include et lib), le code semble bon mais lorsque je compile, erreur ...

Error 2 error LNK2019: unresolved external symbol __imp__glClear@4 referenced in function "public: void __thiscall ax::GameContext::Run(void)" (?Run@GameContext@ax@@QAEXXZ) ...\...\Microsoft Visual Studio 12.0\Project\AxionTest\AxionTest\Axion.lib(GameContext.obj)
Error 3 error LNK2001: unresolved external symbol __imp__glClear@4 ...\...\Microsoft Visual Studio 12.0\Project\AxionTest\AxionTest\Axion.lib(RenderTarget.cpp.obj)

etc...

Merci

Salut,

Tu dois lier les dépendances dans le projet final.

Citation:

---

Envoyé par Bousk

Salut,

Tu dois lier les dépendances dans le projet final.

---

Mais si je dois lier les dépendances des sous libs de Axion.lib, je perd tout l'intérêt d'avoir créé cette bibliothèque. J'ai vérifié j'ai bien ajouté Axion.lib dans les dépendances.

Sérieux, le concept de modularité, tu t'en cogne ?

Citation:

---

Envoyé par bacelar

Sérieux, le concept de modularité, tu t'en cogne ?

---

Quand, on utilise un moteur, l'utilisateur ne veut pas avoir a se soucier des sous libs du moteur ! Je veux juste avoir a link le Axion.lib et terminé.
Après j'ai peut être pas bien compris le concept de modularité, mais dans ce cas je ne pense que ce soit nécessaire...

Tu la fais en lib dynamique, ce qui fait que, par exemple, OpenGL sera linké à ta lib dynamique, et tu ne l'auras plus en dépendance de tes bin.

Citation:

---

Envoyé par dragonjoker59

Tu la fais en lib dynamique, ce qui fait que, par exemple, OpenGL sera linké à ta lib dynamique, et tu ne l'auras plus en dépendance de tes bin.

---

J'ai essayé de la faire en dynamique mais ça ne compile pas ... Je pense que le problème c'est surtout ma logique. Vous le dites si je me trompe:

-Je crée une bibliothèque statique composé de sous libs. Pour cela, je build la bibliothèque statique avec les sous libs en STATIC. Du coup le code compilé des sous libs se retrouvent dans le .lib ( comme lorsqu'on fait un exécutable dans lequel on inclue directement la/les libs ).
Le problème dans mon teste c'est que le projet n'arrive pas à link les sous libs de Axion. Et ça je comprend pas parce que j'ai tout build en static.

Quand tu build en statique, tu peux considérer que ta lib ne contient que ses propres fonctions, et dit qu'elle va avoir besoin des fonctions externes qu'elle référence (mais elle ne les inclue pas).
Donc lorsque tu linkes ta lib statiques, il faut aussi que tu linkes les dépendances de ta lib.

C'est pour cela que je te conseille de passer ta lib en dynamique, car le comportement des libs dynamique est différent.
Ta lib dynamique va effectivement linker le contenu des libs statiques externes qu'elle référence.
Ton exécutable n'a alors besoin de linker que ta lib dynamique.

Si tu as eu des erreurs en linkant ta lib dynamique, peux-tu nous les montrer, pour qu'on t'aide à les résoudre?

Bon alors j'ai réussi à compiler la .dll mais par contre j'ai dû passer certaines bibliothèques (SFML) en dynamique lors de la compilation.
En revanche lorsque je link le projet test à ma .lib (dynamique) ça ne compile pas.

Error 2 error LNK2019: unresolved external symbol __imp__glClear@4 referenced in function "public: void __thiscall ax::GameContext::Run(void)" (?Run@GameContext@ax@@QAEXXZ) G:\...\Microsoft Visual Studio 12.0\Project\AxionTest\AxionTest\Axion.lib(GameContext.obj)
Error 3 error LNK2001: unresolved external symbol __imp__glClear@4 G:\...\Microsoft Visual Studio 12.0\Project\AxionTest\AxionTest\Axion.lib(RenderTarget.cpp.obj)

et j'en passe...

Je avoir trouvé le problème, c'était les libs qui en mode STATIC ne fonctionnent pas, du coup obligé de les utiliser en dynamique...
Donc au final je me retrouve avec 15 milles .dll à placer sauf que c'est pas très propre :/

Est ce qu'il est possible de définir le path des .dll DEPUIS un fichier .hpp (avec les pragma par exemple) ?
#pragma comment (dll, "Engine/bin/") par exemple.

J'ai rien trouvé de cela mais en gros le but ça serait de mettre tous les .dll dans un fichier Engine qui est nécessaire pour lancer l'exécutable :)
Pour les libs il n'y a pas de problème:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

#define AXION_API __declspec(dllexport)   #ifdef _DEBUG #pragma comment(lib, "SFML/sfml-graphics-d.lib") #pragma comment(lib, "SFML/sfml-window-d.lib") #pragma comment(lib, "SFML/sfml-system-d.lib") #pragma comment(lib, "SFML/sfml-audio-d.lib") #pragma comment(lib, "SFML/sfml-network-d.lib") #pragma comment(lib, "Glew/glew32.lib") #pragma comment(lib, "opengl32.lib") #else #pragma comment(lib, "SFML/sfml-graphics.lib") #pragma comment(lib, "SFML/sfml-window.lib") #pragma comment(lib, "SFML/sfml-system.lib") #pragma comment(lib, "SFML/sfml-audio.lib") #pragma comment(lib, "SFML/sfml-network.lib") #pragma comment(lib, "Glew/glew32.lib") #pragma comment(lib, "opengl32.lib") #endif

---

C'est le problème des DLLs:

1. Faire le code pour ouvrir (LoadLibrary), extraire les fonctions (GetProcAddress), fermer (FreeLibrary). Quoique ce code peut être automatique en incluant dans ton projet un fichier .lib qui fait le travail pour toi
2. Coder un File_Manager pour tester la présence des DLLS, dossiers, fichiers et recréer si nécessaire ce qui est "cassé". À moins que tu t'en remettes à 100% à ton installateur.

Si les DLL sont chargées statiquement (c'est à dire que nulle part dans ton programme tu ne les charges avec dlopen ou LoadLibrary), alors non, le seul moyen, c'est dans ton script de post-build (avec Visual Studio) tu copies les DLL dans le dossier $(OutDir).
Si les DLL sont chargées dynamiquement (avec LoadLibrary ou dlopen), c'est à ton programme de savoir où les trouver. Mais il te faudra de toute façon les copier à un endroit fixe (par rapport à ton exe) pour qu'il puisse les retrouver... en les copiant donc en post-build step (sous Visual Studio toujours... sous Linux ce n'est généralement pas nécessaire, les libs installées étant généralement dans /usr/lib ou /usr/local/lib)

Si l'aspect mise à jour automatique ne vous intéresse pas, je vous conseille chaudement d'utiliser un manifeste pour spécifier le chemin de recherche de vos Dll.


https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

Bon, je pense que je vais faire confiance à l'installateur :D, ça fait presque 4 jours que je suis sur ce problème ça commence à me miner un peu la tête :aie:
Je suis déjà bien content du résultat de tout placer dans un gros fichier "Engine", en plus ça me sera bien utile un jour ou l'autre, pour les shaders par exemple.

Enfin bref, merci beaucoup pour vos conseils/solutions et votre temps !