Version imprimable
Bonjour,
J'ai une question toute bête.
Je suppose que j'ai un exécutable a.out que j'ai
obtenu avec un compilateur g++-4.2.4 sous linux par exemple.
Si je veux le faire marcher sur une autre machine qu'est ce qu'il me
faut sur cette machine:
- un compilateur ?
- un compilateur quelconque ?
- le meme compilateur ? ....
cela dépend, s'il y compatibilité entre les deux machines alors il n'y a rien à faire, c'est d'ailleurs grâce à cela que l'on peut installer des programmes sans les recompiler ;)
en fait la vrai question est qu'est ce qui pourrait poser problème, et bien par exemple :
- l'absence de compilateur pour le système/cpu utilisé
- un code utilisant des spécificités (include, libs) d'un autre système, par exemple si le code utilise les MFC de Windows il sera difficile de le compiler sous Linux
- un code incompatible avec la version du compilateur utilisé, par exemple il n'est pas possible de compiler Qt2.3 avec g++ 4.x alors que cela était possible avec une version 3.x
- un code incompatible avec l'architecture, par exemple un code lié à l'ordre des octets dans les mots (Intel : poids faibles en tête, Motorolla : poids forts en tete) ou à la taille d'un adresse ou d'int (32 ou 64 bits par exemple)
Merci Bruno.
Pourrais tu me conseiller une/des page/s web qui pourraient
m'aider à comprendre ce qui se passe exactement quand on
crée un exécutable (compilation, édition de liens, ...) ou
éventuellement un bon live.
Salut,
Le principe est relativement simple:
La première chose qui est faite, c'est l'interprétation des directives préprocesseur (#define, #include, ...) et la suppression des commentaires.
Cela pourrait tout à fait prendre la forme d'un fichier temporaire, d'ailleurs, il est possible de demander à gcc d'afficher le résultat , voire d'enregistrer le résultat dans un fichier (qui pourrait parfaitement servir comme un fichier source "classique" ;)) avec l'option -E
Les premiers compilateur pasaient par une étape intermédiaire qui consistait en la traduction des instructions (C++) en assembleur.
Tu peux encore, à l'heure actuelle, utiliser l'option -S avec gcc pour demander de te créer le code assembleur, mais, pour autant que je sache, il n'y a plus création systématique d'un tel fichier dans le processus de compilaton.
La deuxième étape consiste donc en la compilation proprement dite: le compilateur traduit toutes les instructions qu'il trouve dans le fichier en instructions compréhensibles par le processeur.
On obtient ce que l'on appelle un "fichier objet" (il a souvent l'extension .o ou .obj, selon le compilateur (cela ne veut absolument pas dire qu'un autre compilateur pourrait utiliser une autre extension :D) )
A ce stade, chaque fichier objet est carrément une partie de l'application, à ceci près que les appels de fonctions ne se trouvant pas dans le fichier objet sont remplacés par des symboles uniques permettant d'identifier la fonction qui devrait effectivement être appelée.
Enfin, l'éditeur (ld sous linux ;)) de liens vient terminer le travail; il va:
- regrouper les différents fichiers objet dans un fichier qui sera... l'exécutable
- "extraire" le code objet des fonctions présentes dans bibliothèque statiques et qui sont utilisées par le programme
- remplacer les symboles des différents appels de fonctions par l'adresse à laquelle les fonctions appelées se trouve effectivement dans l'exécutable
- faire le liens avec les fonctions se trouvant dans les bibliothèques dynamiques (*.dll / *.so)
Pour ce qui est des bibliothèques statiques, l'éditeur de liens ne sera pas utilisé, par contre un créateur d'archive (ar sous linux) créera une archive pour ainsi dire classique avec tous les fichiers objets, puis il y aura création d'un index permettant de retrouver les différentes fonctions plus "facilement" (sous linux, c'est le role de ranlib)
Je n'en demandais pas tant.
Mais maintenant ...
Un grand merci Bruno !
Si ce n'est que c'est pas Bruno qui a donné les explication :furieux::massacre::evil:Citation:
Envoyé par debutant100
Je viens juste de me faire découper à la tronçonneuse ... oh la la !
Ce qui reste de moi est confus.
Mille excuses.
Merci Philippe !!!
Bonjour,
:lol: je me demande qui de Philippe et de moi doit être le plus vexé par la confusion :mouarf:
mais c'est toujours le cas, simplement le support n'est souvent pas un 'vrai' fichier mais un pipe pour des raisons de performances. Il suffit de lancer une compilation et de regarder la liste des processus pour le voirCitation:
Envoyé par koala01
il y a toujours un passage pas l'assembleur, mais ces derniers sont désormais capable de réaliser des optimisations et non simplement faire le passage assembleur symbolique vers binaire, pour certains processeur le code assembleur produit utilise un nombre illimité de pseudo registres, et c'est l'assembleur qui décide de l'utilisation des registres réels.
Surement les deux :mouarf: :king:Citation:
Envoyé par bruno_pages
Je constate une ambiance très ... détendue ...
moi je me sauve de ce post ...