Modif de projet existant VS 2008 : Comment linker les .lib plutôt que d'utiliser des DLL ?

Bonjour,

Je cherche à compiler RRDTool sous Visual Studio 2008, jusque là pas de problème ça compile après quelques adaptations, mais maintenant je veux générer un EXE indépendant contenant toutes les libs en statique plutôt que de fournir l'EXE et les DLL compilées par le projet (cairo, libxml, libpng, zlib...).

Y a-t-il un moyen simple dans les paramètres de compilation du projet pour modifier cela ?

cdlt.

p.s : merci de ne pas essayer de me convaincre que "les DLL c'est mieux", je veux tout linker dans mon .EXE pour ce projet.

Salut,

Pour cela, il n'y a qu'une seule et unique manière de faire : recompiler les librairies en statique. Tu peux changer cela dans les projets des librairies (dans le coin du linker, changer le type de projet vers Librairie statique (.lib)), ou bien avec configure (si tu les compiles comme ça).

Si tu n'as pas les sources d'une librairie, tu ne pourras pas la recompiler, et, donc, pas l'utiliser statiquement.

Ben si tu n'as pas tes librairies externes sous forme de librairie statique, c'est tout simplement mort. On ne peut pas transformer une DLL en librairie statique "comme ça" (l'inverse est possible, par contre, si nécessaire).

Il te faut soit la version binaire de la librairie (le "gros" .LIB, pas celui d'importation de la DLL), soit en avoir les sources et recompiler en librairie statique : Propriétés du projet -> Général -> Type de configuration = "Bibliothèque dynamique (.dll)" à mettre sur "Bibliothèque statique (.lib)".

Si tu n'as ni la version statique, ni les sources, tu ne peux pas te dispenser de la DLL... Il est toutefois possible d'inclure la DLL en tant que ressource de l'exécutable, de la "sortir" à l'exécution via le link faible "Chargement différé des DLL" (Propriétés -> Éditeur de liens -> Avancé)... Il est quand même peu probable que tu sois obligé d'en arriver à ce point.


Il n'empêche qu'il est très simple de livrer des DLL avec un exécutable, y compris en ayant un seul et unique exécutable "visible" pour l'utilisateur (via un vrai-faux setup, notamment)... Cela permet des distributions plus réduites et/ou de ne pas plomber la RAM et le disque dur des utilisateurs, car cela peut être très moyennement apprécié sur des machines un peu chargées.

J'étais sûr que quelqu'un me vanterait les mérites des DLL ;-)

Sinon j'ai bien tous les sources des diverses DLL ainsi que les .lib associés qui ont été générés lors de la compilation. Il me faut donc savoir où aller pour dire au compilateur de prendre les .lib plutôt que les DLL.

cdlt.

Citation:

---

Envoyé par Dodfr

J'étais sûr que quelqu'un me vanterait les mérites des DLL ;-)

---

Ben il y a une raison : les exécutables de 200 Mo, c'est laid, et si tu en lances deux exemplaires, c'est deux fois plus de ressources plombées... :D

Citation:

---

Envoyé par Dodfr

Sinon j'ai bien tous les sources des diverses DLL ainsi que les .lib associés qui ont été générés lors de la compilation. Il me faut donc savoir où aller pour dire au compilateur de prendre les .lib plutôt que les DLL.

---

Tu t'en fiches : dans les deux cas, le compilateur linke le .LIB justement, il te suffit de cocher comme dépendances de ton programme les projets des librairies statiques.
Si tu as "transformé" les projets DLL en projets LIB, il n'y a rien à faire.
Si tu as créé de nouveaux projets pour la version statique, il faut et il suffit de modifier les dépendances du projet principal.

Dans tous les cas, Dependancy Walker t'indiquera explicitement quelles sont les dépendances dynamiques de ton programme.

Enfin là j'ai 3.5Mo de DLL en 12 fichiers donc le statique ne va pas plomber l'EXE surtout que cet EXE n'est pas prévu pour être lancé plusieurs fois simultanément, c'est du calcul RRDTool en batch, par contre ce qui est sur c'est qu'un EXE se lance plus vite en version statique que dynamique.

En fait la Solution est constituée de 2 Projets, RRDLib qui génère un .lib de 3Mo qui contient lui même tous les "petits" .lib des diverses librairies zilb, libxml2, libpng... dans la foulée les .DLL équivalentes (zlib.dll, libpng.dll ...) sont générées.

Le second projets est RRDTool lui même qui génère un EXE de 150Ko qui demande les DLL lors de son lancement. Il me faut donc linker directement rrdlib.lib dans RRDTool.exe plutôt que de le laisser charger les DLL externes.

Avec le chargement différé des dll, tu auras un démarrage à froid aussi rapide et une empreinte mémoire bien moindre.

Le démarrage "à froid" sera peut-être plus rapide mais de toute façon le chargement des DLL sera obligatoire pour utiliser l'appli donc ça revient au même. Mais encore une fois je ne cherche pas à être convaincu que "les DLL c'est mieux". Je les utilise quand c'est nécessaire et si je peux les éviter je le fait, tout comme j'évite si possible les installeurs, la base de registre etc... et mes programmes ne s'en portent pas plus mal.