Discussion :

[Ange_blond]

Bonjour,

Voilà mon petit soucis :

J'utilise une bibliotheque dynamiquement (.dll) pour mon projet.
J'ai besoin de sortir un peu de code de mon projet pour en faire une lib réutilisable par d'autres projets.

Donc c'est là où vient le mais :

Lorsque que je compile mon bout de code en lib statique (pour éviter une dll de plus), le .lib est enorme (22Mo en release) alors qu'il y a a peine quelques milliers de lignes de code...
Ce que je souhaite savoir c'est :
1. est ce que c'est possible de compiler une lib statique qui a des dépendances dynamiques ? (je ne veux pas que le code des dépendances dynamique soit inclu dans mon .lib)
2. si oui, comment ?

Merci.

Ange_blond

[Mac LAK]

Une librairie statique n'est absolument pas liée, ni de près, ni de loin : aucune dépendance n'est résolue, c'est l'exécutable utilisateur (EXE ou DLL) qui effectuera la liaison directe. Par contre, elle subit bien sûr l'inlining et autres formes d'optimisation pouvant modifier plus ou moins fortement la taille du code produit.
A noter que la taille du .LIB n'est pas forcément très significative, à cause des informations de debug et des fonctions "inutiles" qui ne seront pas forcément liées à l'exécutable si tu actives le link au niveau fonction.

Tu peux t'en convaincre sur la page des propriétés d'une librairie statique : il n'y a PAS de section "Édition de liens"...

[Ange_blond]

D'accord, donc ma lib ne va pas chercher à inclure les dépendances de la bibliotheque que j'utilise pour mon projet...

Par contre je comprend vraiment pas comment je m'en sort avec 22Mo pour les quelques classes qu'il y a...
Le soucis étant que plusieurs projet vont utiliser statiquement cette lib, et donc ils vont tous "prendre" 22Mo alors que rares sont ceux qui dépassent le Mo ...

Les options de compil sont en effet réduites, mais peut etre que je rate une étape en cours de route ... ?

[Mac LAK]

D'accord, donc ma lib ne va pas chercher à inclure les dépendances de la bibliotheque que j'utilise pour mon projet...

Non, en effet, c'est une DLL qui ferait ça. Mais tu auras bien sûr besoin des entêtes pour compiler la librairie, bien sûr.
Tu peux (partiellement) inclure les dépendances via un "#pragma comment(lib)", mais ça ne te dispensera pas d'avoir les librairies de dépendances sous le coude pour créer un exécutable ou une DLL utilisant ta librairie statique.

Par contre je comprend vraiment pas comment je m'en sort avec 22Mo pour les quelques classes qu'il y a...
Le soucis étant que plusieurs projet vont utiliser statiquement cette lib, et donc ils vont tous "prendre" 22Mo alors que rares sont ceux qui dépassent le Mo ...

C'est bien le problème avec les librairies statiques, justement !
Essaie quand même de linker un exécutable de test : tu as peut-être beaucoup d'informations de debug dedans, ce qui produira un exécutable assez petit, ou alors, tu as vraiment trop abusé des templates.

[Ange_blond]

Merci

Je vais qd meme tenter à l'occasion un exe de test en effet pour voir s'il embarque pas plus de dépendances qu'il ne faut...

Par contre c pas logique : 22Mo en Release, 8Mo en debug....

Et le truc qui tue : sous linux, la lib en static ou en dynamic ne dépasse pas les quelques centaines de Ko tout au plus. (fait avec NetBeans)

[Mac LAK]

Par contre c pas logique : 22Mo en Release, 8Mo en debug....

Tu noteras, dans les optimisations, que certaines optimisations de vitesse sont diplomatiquement marquées comme "pouvant augmenter la taille de l'exécutable" (au profit de la vitesse d'exécution, donc).

C'est une des raisons pour laquelle je me méfie toujours des templates utilisés n'importe comment et/ou n'importe où...

[Médinoc]

J'ai déjà vu Visual me détecter une fonction de calcul d'un tableau de 16Mo et me remplacer cette fonction par une copie du tableau directement dans l'exécutable produit.
Désactiver l'inlining sur l'unité de compilation concernée (c'était Visual 6, pas de LTCG à l'époque) a résolu le problème.