Discussion :

[Lunixinclar]

Salut à tous, quelqu'un connait-il des options de compilation pour rendre les exécutables plus compacts?

Le hello world suivant:

Code :

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

1
2
3
4
5
6
with TEXT_IO;
 
procedure HELLO is
begin
 TEXT_IO.PUT_LINE ("Hello, World!");
end HELLO;

Compilé avec

Code :

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

gnatmake -q hello.adb -o hello.adb.exe

Produit un exécutable de 20811 octets...
Ca me rend fou car certains OS tiennent sur une disquette.
Des suggestions?

[Seb_de_lille]

Effectivement, c'est un problème connu d'Ada. Je suis également preneur d'une solution pour limiter la taille des exe.

[Hibou57]

Produit un exécutable de 20811 octets...
Ca me rend fou car certains OS tiennent sur une disquette.
Des suggestions?

Moi z'aussi la zestion, heuuu, question m'interesse. Je fais une réponse partielle (je repasserai avec les options)... mais avant : une remarque.

La chose à savoir, c'est que Ada défini un mini sytème autosufisant : c-à-d Lunixinclar, que la runtime Ada est justement un mini OS a elle toute-seule. Ce qui explique la taille des exe.

La réponse partielle :

Ada fait inévitablement penser à Turbo-Pascal, pour ceux/celles qui ont connu. Et pour ceux/celles qui ont eu le bonheur de travailler sous l'inégalé EDI de Borland, le fichier d'aide disait à-peut-prêt ceci : « n'ayez pas peur d'ajouter autant de choses que vous le voulez dans vos unités, le compilateur se chargera d'éliminer tout ce qui n'est pas effectivement utilisé ». C'est ainsi que même en créant une application qui référençait une TPU de plusieurs Kb, on pouvait garder un binaire tout petit. A contrario, en C/C++, j'ai pleuré à cause de ça : vous liez à un fichier objet énorme, même si vous n'utilisez qu'une-seule routine de ce fichier objet, le binaire sera énorme... à moins de recréer votre « package », en faisant un fichier source pour chaque procédure/fonction, d'avoir donc aprés compilation un fichier objet par procédure/fonction, et de tout mettre dans une librairie (je me voit encore découper mes gros sources en une multiple de petits fichier avec un nom numéroté, et compiler tout ça pour en faire une librairie de plein de petits fichiers objets).

Gnat peut se comporter comme Turbo-Pascal, et éliminer tout ce qui est contenu dans une unité (package en Ada) et qui n'est pas effectivement utilisé par le code. Seulement Gnat (je suppose que vous êtes sous Gnat, vu que c'est LE monopole, sniffff), s'il peut le faire, ne peut pas le faire aussi directement que Turbo-Pascal. Avec Gnat, il y a une option. Et il faut compter une passe supplémentaire, parce qu'il doit analyser votre application pour savoir ce qu'il va pouvoir éliminer. Il produira un fichier d'information sur les éliminations possibles, à la suite de quoi il faudra demander à appliquer ces éliminations. Il faut donc demander la création de ce fichier, puis l'application des coupes sombres.

Je n'ai pas l'option en tête, j'en suis à des essais d'autres natures pour le moment. Je retrouverai, et je repesserai vous donnez plus détails.

@+

[Lunixinclar]

Oui, le compilateur joue un rôle essentiel puisque c'est lui qui produit l' exécutable. En fait je ne comprend pas la relation entre le compilo gnat et gcc. Parce qu'en passant l' option -s à gcc, celui-ci retire les symboles de la table d' allocation, produisant de fait un exe bien plus modeste.
Ca peut être fait manuellement quand même:

Code :

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

1
2
3
$ strip hello.adb.exe
$ wc -c hello.adb.exe
7688 octets

Trois fois plus petit qu'avant. Mais deux fois plus gros qu'un programme C, juste pour un hello world ça fait quand même beaucoup d' octets nan?

[Hibou57]

C'est quoi « wc » ? Une compression des exe ?

Bon, j'ai fait des essai avec gnatelim, qui est censé permettre de réduire la taille des exe. Je ne vais pas te détaillé la procédure (longue), ce serait inutile, parce que les résultats sont franchement nuls.

En plus d'être nul, le résultat est même paradoxal.

Sans gnatelim : hello.exe fait 213 KB et 68 KB aprés un strip sur l'exe

Avec gnatelim : hello.exe fait 127 KB et 83KB aprés un strip sur l'exe

Tu vois ce qui cloche ? .... avec gnatelim, l'exe est effectivement plus petit aprés la compilation, mais si tu fais un strip sur l'exe, tu t'aperçois que tu obtiens un exe plus gros que celui de la ligne précédente, malgré que l'exe avant strip soit plus petit que celui de la ligne précédente.

J'ai tout essayé concernant gnatelim, même la recompilation en analysant les librairie système. Rien n'y fait, le résultat est exactement le même.

A titre de comparaison, j'ai un petit programe d'essai GUI qui fait sensiblement les mêmes tailles que ce programme d'essai en console...

En fait, cette taille monstrueuse pour les petites applications ne doit pas laisser croire qu'il y a un facteur d'acroissement par exemple par rapport au exe produit à partire de sources C. Cela semble être une constante, un ajout de taille fixe et incompressible à tous les exe produits. Donc cela se voit beaucoup sur un petit programme, mais ça ne se voit pas pour les gros programme.

Mais c'est vrai qu'il y aurait des effort à faire à ce niveau...

Désolé d'avoir promis de repasser avec une solution, puisque cette solution ne fonctionne pas. Si j'ai du neuf, je t'en parlerai ici. Mais je crois quand même que c'est la runtime qui pose problème. Il y a une pragma spécifique à gnat, « No_Run_Time », mais les routines de Text_IO par exemple, nécéssite cette runtime, parce que c'est dans la runtime qu'est implémenté par exemple Text_IO.Put_Line.

Une alternative serait de créer une runtime anexe pour les petits programe (parce que c'est vrai qu'il y a un intêrêt à utiliser Ada même pour les petits programme... clarté et propreté oblige).

[Hibou57]

Voici une petite expérience simple, pour avoir une idée de l'espace occupée par la Run-Time Ada. Ce teste est effectué avec Gnat3.15p, et tire partie d'une pragma spécifique : pragma No_Run_Time;

Créez une source ada contenant le code suivant :

Essai.adb

Code :

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

1
2
3
4
5
 
procedure Essai
is a: Integer;
begin a := 1;
end;

Une application trés-trés simple donc...

Compilez avec gnatmake, sans options.

Compilation normal: 148KB, et 32KB aprés un strip sur l'exe

Créez maintenant dans le même repertoire que Essai.adb, un fichier nomé gnat.adc, dont le contenu sera le suivant :

gnat.adc

Code :

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

1
2
 
pragma No_Run_Time;

Compilez à nouveau, avec la commande gnatmake habituelle, exactement la même que précédement (n.b. n'oubliez pas de supprimer les fichier essai.exe, essai.ali et essai.o au préalable, ou d'utilisez l'option -f pour gnatmake, pour forcer la recompilation même en l'abscence de modification des sources).

Compilation sans Run-Time: 16KB, et 3KB aprés un strip sur l'exe

De cette expérience simple, nous pouvons tirer deux conclusions importantes

1) La runtime Ada pèse lourd : 132KB sur un exe non-stripé, et 29KB sur un exe stripé (valeurs approximatives).

2) Le compilateur ne fait aucun effort pour supprimer les liaisons inutiles. On reconnait aisément que l'application Essai ne nécéssite pas de runtime, et quand on voit le code de l'application, on peut s'étonner qu'il ne le fasse pas.

Il y avait une Run-Time incompressible également avec Turbo-Pascal pour DOS... mais elle ne pesait que 512 octets, et la plus grande part de la Run-Time était éliminée de la liaison quand elle était inutile.

Je n'ai pas le temps tout de suite (faut que je sorte), mais il serait interessant de mettre gnatelim à l'épreuve sur cette application : saurat-il oui ou non éliminer les liaisons inutiles ? La suite au prochain épisode (à cette occasion, j'expliquerai rapidement comment fonctionne gnatelim, parce qu'il est un peu lourd).

P.S. Même sans runtime, et une fois stripé, l'exe pèse encore 3K. Et c'est quand-même encore beaucoup pour une application de ce genre. Et quand on voit la différence de taille entre la version stripée et la version non-stripée, 13KB, on se demande où se trouve les justifications à placer 13KB de symbole dans un exe de ce genre : quelles dépendances ? Et si ce n'est pas la runtime, puisqu'on la éliminé, qu'est-ce donc alors encore ?

[HRS]

pour réduire la taille de l'exe en même temps que sa fabrication

gnatmake titi.adb -largs -s

[Hibou57]

pour réduire la taille de l'exe en même temps que sa fabrication

gnatmake titi.adb -largs -s

Oui, mais c'est juste un strip automatique à la liaison. Et le strip n'est pas probant, l'exe reste quand même énorme, même pour une toute petite application minuscule de rien du tout.

[Hibou57]

Après plusieurs tentatives et tests de plusieurs solutions, il s'avère que GNAT est handicapant pour les petites applications. Ce qui est dommage, car Ada est interessant même pour les petits projets (ne serait-ce que pour rester dans les bonnes habitudes), et pas seulement pour les grand systèmes. Il faudra donc bien prendre garde à ne pas confondre ce défaut inhérent à Gnat avec un défaut inhérent à Ada. Gnat est en cause, mais pas Ada. Dommage tout de même.

Pour les détails de la méthode à suivre : comment réduire la taille des exécutables produit par Gnat.

Accessoirement, vous pourrez consulter ce résumé du guide d'utilisation de Gnat.

[Hibou57]

Comme je disais lors de l'une des précédentes réponses, l'avantage de l'environnement TurboPascal était qu'il était capable d'exclure de la liaison, les éléments non effectivement utilisés par un programme.

Eh bien apparement il est possible d'obtenir un résultat similaire avec GCC. Seulement le hic, c'est que ça ne semble pas fonctionner correctement sous Windows.

Il existe deux options de GCC, qui sont « -ffunction-sections » et « -fdata-sections », qui commande au compilateur de placer chaque procédure/fonction dans une section individuelle du fichier objet produit, et de même pour chaque données du programme.

Ensuite, une option du lieur, qui est « -wl,--gc-sections » (apprently, garbage collect sections) qui peut éliminer de la liaison tout ce qui n'est pas effectivement utilsé par le programme.

Notez qu'en invoquant gnatmake, on emploie les options -cargs et -largs pour respectivement passer des options à GCC et à ld.

Alors, le hic maintenant : étrangement, GCC semble bien reconnaître l'option -ffunction-sections, mais pas l'option -fdata-sections... ce qui est paradoxal (pourquoi le GCC sous Windows serait-il capable de produire des sections individuelles pour les procédures/fontions, mais pas pour les données). Et ensuite, au niveau du lieur, il existe un problème similaire : il semble reconnaître --gc-sections, mais pas -wl (bien que je crois que --gc-section, soit elle-même un paramètrage de -wl)

..... bon, bon, bon ... que faire, que faire