probleme pour comprendre l'édition de lien

[cosmoff]

Bonjour,

voila prenons un code tout simple :

#include <iostream>
int main() 
{
    int a = 10;
    std::cout << "La valeur de a est " << a << std::endl;
}

quand je compile mon fichier main.cpp il subit plusieurs transformations :
1/le compilateur remplace #include <iostream> par le contenu du fichier iostream.h planqué quelque part dans le PC
2/transforme le code en assembleur puis en binaire
3/on fait l'édition de lien c'est a dire on rajoute du contenu binaire dans le programme. Mais apres l'étape 2 tout est en binaire, donc pourquoi rajouter des choses encore alors que tout est mis? De plus le compilateur à l'étape 2 transforme tout en binaire, donc comment le compilateur sait à quelle adresse va se trouver des fonctions qui ne vont apparaitre qu'a l'édition de lien

je m'excuse d'avance car c'est pas très claire.

Merci d'avance pour vos explications
-----

[pm42]

2/transforme le code en assembleur puis en binaire

En fait, on ne fait plus l'étape assembleur. On génère un fichier .o directement en binaire. Mais ce n'est pas important.
Ce fichier peut référencer des fonctions qui sont des librairies, dans d'autres fichiers pas encore compilés...

3/on fait l'édition de lien c'est a dire on rajoute du contenu binaire dans le programme.

Une fois qu'on a tout compilé, on a un programme complet c'est à dire qu'on sait où sont toutes les fonctions.
On prend donc tous les .o et on génère le programme final en remplacant les liens incomplets de l'étape précédente par les vraies valeurs.

[cosmoff]

Ok, merci pour ton explication. Mais il me semblait que les fichiers pour l'édition de lien avaient des extensions en .so .a (linux) et .lib .dll (windows) donc pendant l'édition de lien c'est fichier sont compilés pour devenir des .o ou je mélange un peu tout ?

[pm42]

Mais il me semblait que les fichiers pour l'édition de lien avaient des extensions en .so .a (linux) et .lib .dll (windows) donc pendant l'édition de lien c'est fichier sont compilés pour devenir des .o ou je mélange un peu tout ?

.a = librairie en linux, même chose que .lib en Windows
.so et .dll = librairie dynamique : on ne la copie pas dans l'exécutable final, on la charge au lancement et c'est à ce moment que se fait l'édition de lien qui la concerne. L'avantage est de diminuer la place sur le disque et en mémoire. L'inconvénient est que cela nécessite que toutes les librairies dynamiques nécessaires à un programme soient dispos et dans le bonne version (ce qui est parfois appelé "l'enfer des DLLs" sur Windows)

L'édition de lien se fait avec les .o entre eux et entre les .o et les .a/.lib. Pour les .so/.dll comme déjà expliqué, on vérifie juste que tous les liens sont corrects mais elle ne se fait vraiment qu'au lancement.

[A voir en vidéo sur Futura]

[cosmoff]

ok c'est beaucoup plus claire, merci pour toutes tes précisions

[albanxiii]

Quand on débute, je trouve que le terme bibliothèque est à préférer au mot librairie qui, dans ce contexte, vient de l'anglais librairie.
Quand on a commencé à me parler d'édition des liens, je ne voyais pas trop ce qu'une librairie venait faire là dedans.
Après il y a les usages professionnels, mais ça, c'est après

[pm42]

Ce n'est pas faux.

[CM63]

L'expression "édition de lien" est également issue d'une mauvaise traduction de l'anglais.

[invite0bbe92c0]

mot librairie qui, dans ce contexte, vient de l'anglais librairie.

de l'anglais library, plutôt

[jacknicklaus]

Mais apres l'étape 2 tout est en binaire, donc pourquoi rajouter des choses encore alors que tout est mis? De plus le compilateur à l'étape 2 transforme tout en binaire, donc comment le compilateur sait à quelle adresse va se trouver des fonctions qui ne vont apparaitre qu'a l'édition de lien

En fait, l'étape d'édition de lien (link edit) sert surtout à effectuer (mettre à jour) des liaisons entre les différents modules objets, compilés séparément. D'où le terme de "link edit".

Si tu as 2 sources S1 et S2 qui donnent deux objets O1 et O2, et si dans S1 tu utilises une fonction F2 définie dans S2, l'objet O1 contient un référence vers un objet certes déclaré dans S1 (sinon compilateur pas content) mais dont l'implémentation est inconnue lors de la compilation de S1 qui fabrique l'objet O1.

C'est à l'édition de lien que cette référence sera résolue et qu'un lien (un pointeur) sera matérialisé entre le bout de code de O1 qui appelle la fonction F2, et le point d'entrée de F2 qui est localisé dans O2.

Même principe pour les liens vers les points d'entrée de fonctions en bibliothèque.