g ++ produit de gros fichiers binaires malgré un petit projet

Question

C’est probablement une question courante. En fait, je pense l'avoir demandé il y a des années ... mais je ne me souviens plus de la réponse.

Le problème est le suivant: j'ai un projet composé de 6 fichiers sources. Chacun d'eux pas plus de 200 lignes de code. Il utilise de nombreux conteneurs STL, stdlib.h et iostream. Maintenant, l'exécutable a une taille d'environ 800 Ko ... J'imagine que je ne devrais pas lier statiquement de bibliothèques. Comment faire cela avec GCC? Et dans Eclipse CDT?

EDIT: En répondant loin de ce que je veux, je pense que c'est le cas pour une clarification. Ce que je veux savoir, c'est pourquoi un si petit programme est si gros et quelle est sa relation avec les bibliothèques statiques partagées et leur différence. Si l'histoire est trop longue à raconter, n'hésitez pas à donner des indications à Google. Merci

Answer 1

Si vous attribuez un nom à la bibliothèque dynamique g ++ et ne passez pas l'indicateur -static, le lien doit être lié dynamiquement.

Pour réduire la taille, vous pouvez bien sûr strip binaire et passer l'indicateur d'optimisation -Os (optimiser pour la taille) à g++.

Answer 2

Une chose à garder à l'esprit est que l'utilisation de la STL entraîne la présence de ce code supplémentaire dans votre exécutable même si vous vous liez de manière dynamique à la bibliothèque C ++. Ceci est dû au fait que la STL est un groupe de modèles qui ne sont pas réellement compilés tant que vous n'avez pas écrit et compilé votre code. Étant donné que la bibliothèque ne peut pas anticiper ce que vous pourriez stocker dans un conteneur, il est impossible pour la bibliothèque de déjà contenir le code pour cette utilisation particulière du conteneur. Il en va de même avec les algorithmes et tout le reste de la STL.

Je ne dis pas que c’est définitivement la raison pour laquelle votre exécutable est beaucoup plus volumineux que prévu. Mais cela peut être un facteur.

Answer 3

Eclipse devrait être lié dynamiquement par défaut, sauf si vous avez défini le drapeau statique sur l'éditeur de liens dans votre fichier makefile.

En réponse à votre modification:

- lorsque vous créez un lien statique, l'exécutable contient une copie complète de chaque bibliothèque à laquelle vous êtes lié.
-Lorsque vous liez de manière dynamique, l'exécutable ne contient que des références et des liens avec les bibliothèques liées, ce qui représente une quantité de code beaucoup plus petite.

Answer 4

L'exécutable doit contenir plus que votre code.

À tout le moins, il contient du code de démarrage, définissant l'environnement et, si nécessaire, chargeant des bibliothèques externes, avant le lancement du programme.

Si vous avez lié de manière statique la bibliothèque d’exécution, vous la récupérez également dans votre fichier exécutable. Sinon, vous n’obtenez qu’un petit bout, juste assez grand pour rediriger les appels système vers le moteur d’exécution externe.

Cela peut, en fonction des paramètres du compilateur, inclure également de nombreuses informations de débogage et d’autres données non essentielles. Si les optimisations sont activées, la taille du code a peut-être également augmenté.

La vraie question est pourquoi est-ce important ? 800KB s'adapte toujours facilement sur une disquette! La plupart de cela est un coût ponctuel. cela ne signifie pas que si vous écrivez deux fois plus de code, cela prendra 1600 Ko. Plus probablement, il faudra 810Ko ou quelque chose comme ça.

Ne vous inquiétez pas des coûts de démarrage ponctuels.

Answer 5

Utilisez les indicateurs -O3 et -s pour produire le fichier binaire le plus optimisé. Consultez également ce lien pour plus d'informations.

Si vous créez pour Windows, envisagez d'utiliser le compilateur Microsoft. Il produit toujours le plus petit binaire sur cette plate-forme.

Answer 6

La taille entraîne généralement la liaison de bibliothèques statiques dans votre application.

Vous pouvez réduire la taille du fichier binaire compilé en compilant les versions RELEASE, avec des optimisations à la taille binaire.

Les bibliothèques sont une autre source de taille d’exécutable. Vous avez dit que vous n'utilisiez pas de bibliothèques externes, à l'exception de STD. Je pense donc que vous incluez le runtime C avec votre exécutable, c'est-à-dire que vous liez de manière statique. alors vérifiez les liens dynamiques.

IMO vous ne devriez pas trop vous inquiéter à ce sujet, mais si vous êtes vraiment paranoïaque, vérifiez ceci: Le plus petit x86 ELF Bonjour tout le monde

Answer 7

utilisez Visual C ++ 6.0 pris en charge avec Windows 95 à Windows 7. et peuvent être compilés en tant que plates-formes x86 mais uniquement pour Windows. Donc, si vous êtes un utilisateur Windows, contentez-vous des compilateurs Windows autres que GCC, ce qui est vraiment un sux. La plupart des gens qui disent que Visual C ++ est un sux parce qu'ils sont anti-Microsoft. n'oubliez pas également d'utiliser " Visual C ++ 6.0 " Si vous utilisez une version plus récente, vous ne pourrez probablement pas exécuter vos fichiers sous Windows 95. J'ai testé toutes ces choses, c'est pourquoi je vous l'ai dit. GCC produit les fichiers binaires les plus volumineux, mais pas Visual C ++, Intel Compiler peut économiser plus de 30% d’espace, mais requiert un processeur Intel, à moins que les performances ne soient horribles. Une autre chose que vous devez vous rappeler est lorsque vous utilisez des modèles si vous voyez des petites lignes lorsque vous compilerez ces fonctions seront développées de sorte que le résultat sera de créer des fichiers binaires plus volumineux. si vous avez besoin de fichiers binaires plus petits, je suggère de passer à C car C est très utilisé mais pas OO En fait, C est facile à utiliser que C ++ cela a un sens alors exemple C ++

cout < < " Bonjour le monde " < < endl; printf ("% s " " Bonjour le monde ");

La deuxième indique que le champ d'impression% s signifie que vous tapez une chaîne, donc c'est facile. : P