J'utilise GCC 3.2 sous linux
 
Je compile un programme C qui ne contient que ces lignes :

Le .c fait 31 octets (normal). Le .s en fait 274 (pourquoi pas). Le .o en fait 618 ou 626 octets suivant si je pars du .c ou .s, les deux fois en compilant avec l'option -s
Et enfin le programme compilé avec -s fait 2704 octets.
Je précise que l'option -O2 ne change pas les tailles.
 
Je voudrais savoir pourquoi le .o et l'executable sont si gros ??
 
Merci

Je n'ai pas de réponse précise. Peut-être qu'en étudiant la structure des binaires sous Linux (c'est toujours du ELF ?), tu auras la réponse ?
 
Petit contribution : avec "cc" sous Solaris (m'ont sucré gcc ), le binaire fait près de 4ko. D'après l'entête, c'est du ELF.

bin y'a du code qui se rajoute avant et apres le main(), + le bins propre a un fichier executable
 

4ko ? c'est ptet la taille utilisée sur le disque ça, pas la taille réelle. Tu l'as vu avec ls ou avec du ? Il faut uiliser ls pour avoir la taille réelle (désolé si c'est évident pour toi )
Sinon si je fais un objdump sur le fichier .o j'ai une section text d'environ 20 octets et une section comment d'environ 50 octets.
Donc je ne sais pas trop ce qui prend de l'espace

 
4812 octets pour être précis  

 
j'ai essayé en appelant pas la fonction main et en faisant juste le .o, il fait aussi environ 600 octets

ué mais dans le .o t'as aussi d'autres infos que ton code propre, des infos (symboles...) qui seront utilisées par le linker pour batir ton exe final
 
pis bon, bref, on est en 2005, on va pas s'arracher pour 600octets non ? ou tu fais un concours de plus petit exe ?

 
j'ai compilé en -s (strip) => pas de table de symbole normalement.
et d'autre part l'exe est vraiment gros, le format ELF requière vraiment dans les 2000 octets ?
 
et c'est pour faire une application très petite justement, donc c'est pour ça que je m'intéroge sur les mécanismes de compilation (même si au final ça me servira ptet à rien).

bin, petite, petite, ton exe grandira pas de fonction exponentiel, hein ? donc genralement tu peux oublier ces 3ko initiaux et passer a autre chose. Si maintenant tu grapilles chaque octet (concours ou jsaipakoi), regarde comment virer les libs standarts, ce genre de truc. Y'a de la doc sur le net mais je sais plus ou

(Et encore, tu n'es pas en mode debug...).
 
Ca dépend de l'implémentation, et ça n'a rien à voir avec le langage C. Ca a vraiment une importance ?

peut-être que oui, peut-être que non, je ne le saurai que quand j'aurai la réponse
 
et au moins pour ma culture générale, oui
 
EDIT : j'ai trouvé l'option -nostdlib pour gcc qui permet déjà de comprendre des choses, ça fait gagner dans les 1600 octets, je crois que les options de gcc peuvent m'apprendre pas mal de choses sur la compilation, mais si vous connaissez un bon site à ce propos ça m'intéresse toujours

Tu as beau stripper, si tu compiles un objet il faut bien stocker le nom des fonctions non statiques quelque part, pour l'edition de liens.

Il y a aussi un runtime, il me semble.

Bonjour
Pour gagner de la place, sstrip sur ton executable devrait l'alléger pas mal.
La solution ultime est de faire un programme en assembleur qui n'utilise que les fonctions systèmes standards par passage des paramètres dans les registres ce qui ne demande aucune bibliothèque à l'exécution; un ld pour produire l'exécutable (il n'y a rien à lier) un sstrip pour supprimer tous les 0 et on arrive à des tailles d'exécutables très réduites.
Cordialement