c est quoi la difference en un object, une library, et une archive

que c'est pas français ni standard

Grosso modo, un « object » c'est un binaire généré par le compilo. Ca n'est pas exécutable : c'est destiné à être linké, statiquement (par le linker, à la compilation) ou dynamiquement (par le binder, à l'execution) à d'autres objets ou a un exétuable.
 
Une « archive » c'est un fichier qui contient plusieurs « shared objects ». C'est juste un moyen de regrouper tout ca en un fichier. Par exemple sous unix c'est un fichier « .a » généré par l'archiveur historique « ar ». Tu peux voir le contenu d'une archive avec « ar -t file.a ».
 
Une « library » (bibliothèque en français mais souvent appelée librairie, d'ailleurs je dis librairie et j'ai tord) c'est un binaire ou un ensemble de binaires qui « exportent » des symboles (fonctions, variables) destinés a être utilisés dans un programme. Il y a des librairies statiques et des librairies dynamiques. Un librairie statique est « integrée » dans ton programme a l'édition de lien (au moment de la compilation). Ca grossi donc ton programme. Une librairie dynamique est livrée séparément, et est chargée par ton programme a l'exécution. Ca ne grossi pas ton programme.
 
Concretement un librairie ça peut se présenter sous la forme d'un fichier objet (.o ou .so), d'un répertoire avec plusieurs fichiers objets a l'intérieur, ou encore d'un fichier archive.

euh, la difference est un peu flou:
si je fait

j obtient un objet qui est une somme de plusieurs objet. donc est ce que c est une Archive (.a) ou un Object (.o), ou bien meme un SharedObject (.so) ?

Un objet non partagé est incorporé dans ton programme executable au moment de la generation de cet executable.
 
Un objet partagé n'est pas incorporé dans ton programme, mais lors de l'execution de ton programme, l'objet partagé vas etre mis en memoire, et utilisé par ton programme. Partagé signifie qu'il peut etre partagé par plusieurs programmes qui en chargeront chacun une copie en memoire.
 
Avantage des .so: ne mange pas de place, et il y a moyen de ne pas charger en memoire si il n'est pas utilisé.
inconvenient: si un .so est modifié, pour un programme, il risque de ne plus marcher avec un autre...
 
A+,

 
Non justement : le « texte » de l'objet (le code) est chargé une seule fois en mémoire. Tous les programmes linkés dynamiquement vont utiliser le même texte. Les data par contre ne sont pas partagées et sont « recopiées » a chaque fois.
 
Concretement a la compilation, chaque appel a une fonction de cet objet est traduite un saut vers du « glue code ». Ce sont quelques instructions qui vont chercher dans la stack l'adresse exacte de la fonction cible (celle de l'objet partagé). Et cette adresse est écrite par le binder au début de l'exécution.

Ca doit dependre de flags au link, ca, non?
Fait un peu plus d'un an que j'y ai pas touché, alors c'est plus totalement frais dans ma memoire, surtout que si il y a bien un truc inhomogene entre les differentes plateformes UNIX, c'est bien ca.
A+,