On Thursday 10 October 2002 09:05, Leopoldo Ghielmetti wrote: > so signifie "shared object" (si je ne trompe pas), c'est � dire obj�t > partag�. Il s'agit d'une librairie qui est charg�e par les logiciels de > fa�on dynamique selon les b�soins. Sous Windows ils ont invent� les .DLL > pour faire la m�me chose.
Petite pr�cision technique. Les *.so signifient bien "shared objet" mais sont vraiment des "shared librarues'. Quelle diff�rence y-a-t-il ? Les librairies *.so sont comme les *.a (les *.o ne sont que des relogeables, pas des librairies). Dans le premier cas, le *.so inclus des informations lui permettant d'�tre utilis� dynamiquement, alosr qu'un *.a est une librairie dont le code sera enti�rement inclus avec le programme principal (ou une autre librairie *.a). Ces librairies *.a sont docn appell�es "statiques" car, si l'on modifie sont contenu, il faur "relinker" le programme. De plus, si 5 programmes ont "limk�s" uen librairie *.a et qu'ils s'�x�cutent en m�me temps, il y aura 5 fois le code de la librairie ne m�moire (~ suivant les pages de code acc�d�es, mais �a va assez loin dans les explics...). Par contre, l'avantage est de pouvoir livr� un code qui s' �x�cutera forc�ment avec la bonne librairie et garanti de ne pas interf�rer avec d'autres versions install�e; mais si cette librairie fait appel a des API externes qui ont �t� modifi�s depuis le "link", il y a des chances que le code ne fonctionne plus. Il faut alors une nouvelle version du "programme" ! Autre d�savantage, le temps de link est plus long et le code est gros. A contrario, les *.so ne sont pas "incluses" dans le code ex�cutable du programme et le "linker" se contente d'enregistrer le PATH permettant de "charger" cette librairie � l'�x�cution du programme (SHLIB_PATH �a vous dit quelque chose ?). On peut aussi d�cider de "charger" une librairie lors de l��x�cution d'un programme � l'aide de l'appel syst�me dl_open(2); mais �a c'est une autre histoire. Or, comme plusieurs programmes vont acc�der au "m�me" code, le kernel aura le code de cette librairies en m�moire dans une zone s�par�e (SHARED) du code du programme (TEXT). Tout naturellement, on en est arriv� � pouvoir partager le m�me code entre plusieurs programmes; d'o� le nom "Shared libraries". Toutefois, l'acc�s aux symboles de la librairie se fait en introduisant un niveau d'indirection (pointeur), puisque les adresses relatives sont "mapp�es" par chaque programme � l'ex�cution (PIC) Ce qui implique de compiler avec une option sp�ciale (-shared). L'avantage ? Du code beaucoup plus compact (sur disque ET en m�moire), une seule et m�me version (les bugs et le nouvelles fonctionalit�s sont int�gr�s imm�diatement sans avoir � recompiler TOUS les programmes). Inconv�nients ? Entre autre... celui qui d�veloppe un *.so ne devrait pas changer les API (assurer le compatibilit� arr�ere svp !), o� alors faire une nouvelle version de la *.so. Les num�ros de version sont ajout�s comme suffixe au nom de la librairie (comme mentionn� dans les mails pr�c�dents). Pour plus d'infos, vous pouver consulter la commande gcc(1). Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se d�sabonner aussi.
