2.7 Mo le HelloWorld en rust

En effet, @entwanne dit vrai, la compilation est en statique par défaut ; pour étudier le code, le moyen le plus simple est de compiler en dynamique en passant l’argument -C prefer-dynamic au compilateur.

pourriez vous me simplifier la notion de binaire statique / dynamique ?

En très simplifié :

Soit le programme suivant, en pseudo-code :

importe bibliothèque standard

fonction principale {
    affiche Bonjour
}

La fonction affiche n’est pas définie dans mon code. Elle vient d’ailleurs. Mon code compile quand même parce que la fonction est définie dans la bibliothèque standard, que j’importe.

La question est quand et comment.

• Si, lors de la compilation, je prends toute la bibliothèque standard, avec toutes ses fonctions (au moins toutes les fonctions que j’utilise), et que je les mets dans mon exécutable avec mon code compilé, ce sera un binaire statique.
• Si je ne mets dans le binaire que mon code, mais que je charge tout au lancement du programme, j’aurai un binaire dynamique. Par contre, la bibliothèque appelée devra être présente sur la machine où le code est exécuté dans un emplacement que mon programme va chercher. Si la bibliothèque est absente, ou qu’une bibliothèque avec le même nom mais pas les bonnes fonctions est trouvé, ça ne va pas marcher. Si elle existe avec les bonnes fonctions, mais qu’elles ne renvoient pas les bonnes choses, le programme va se lancer mais ne pas réagir correctement. Si la bibliothèque n’est pas trouvée, il faut changer le chemin de recherche (variable d’environnement LD_LIBRARY_PATH sous Linux, par exemple) pour qu’elle le soit.
• Je peux aussi demander que la bibliothèque soit importée durant l’exécution de mon programme et non pas au début. Ainsi, le programme plantera durant l’exécution si la bibliothèque n’est pas trouvée.

Intérêt et inconvénients de chaque méthode :

• En statique, c’est plus lourd. Par contre, ça marche sur toutes les machines compatibles avec le code sans avoir besoin d’installer quoi que ce soit.
• En dynamique, c’est plus léger (disque et mémoire). Si la bibliothèque est utilisée par deux programmes en même temps, comme ils utilisent la même, elle n’est chargée qu’une fois. Par contre, la bibliothèque doit être présente, au bon endroit, et dans la bonne version. Si une version incompatible avec le même nom est présente, le programme va buguer. C’est donc moins stable dans le temps.
• Le chargement à la volée (dlopen) est utile pour les extensions. Le but est de mettre plus de fonctionnalités, mais sous conditions. Par exemple, je fais un programme qui peut se connecter à 4 base de données différentes. Je ne veux pas charger les 4 bibliothèques associées au démarrage, je ne veux même pas dépendre d’elle (sinon, les 4 bases de données doivent être installées sur la machine). Lorsque j’appelle une base de donnée précise, je charge la bonne bibliothèque, et je renvoie une erreur si elle n’est pas présente. Ainsi, je ne dépends pas au démarrage d’autre programme, mais j’ai quand même plein de fonctionnalités.

Tu peux rajouter -C opt-level=s à la compilation pour que Rust optimise la taille du binaire. Chez moi, il passe de 18 à 13 ko.

Après, si tu veux utiliser un débogueur, tu as l’option-g qui va ajouter les symboles de débug (20ko au final), mais va t’aider à te repérer dans le programme.

Pour étudier le binaire, je pense que le mieux est en dynamique. Car le statique contient plein d’autre trucs, et avec dlopen, ça rajoute une couche potentiellement complexe.

Après, j’ai pas bien compris où tu veux en venir. Si tu ne savais pas ce qu’étais la différence statique / dynamique, je ne suis pas sûr que tu arrives à sortir quelque chose d’intéressant du code désassemblé.