On Thu, 10 Oct 2002, Daniel Cordey wrote: > "charger" cette librairie � l'�x�cution du programme (SHLIB_PATH �a vous dit
LD_LIBRARY_PATH sous GNU/Linux et Solaris. > l��x�cution d'un programme � l'aide de l'appel syst�me dl_open(2); mais �a dlopen(2), standard sur SYSVR4 et GNU/Linux. > relatives sont "mapp�es" par chaque programme � l'ex�cution (PIC) Ce qui En fait, il me semble bien que PIC signifie position-independant-code, ce qui en r�gle g�n�rale implique l'utilisation de l'adressage relatif dans le code assembleur g�n�r� par le compilateur, ce qui est moins efficace. En th�orie une technique de correction d'adresse/mapping est possible, encore que cela impliquerait des tables de saut par processus. Je ne sais pas quel est l'�tat de la technique � ce niveau. > 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. Une alternative, notamment utilis� par le kernel, est de signer les prototypes des fonctions. Lorsqu'un module est ins�r�, il suffit que les signatures soient identiques et dans le cas g�n�ral cela suffit pour assurer la compatibilit� syntaxique (la compatibilit� s�mantique, ie ce que fait r�ellement la fonction est une autre histoire: mais l'on devrait bien s�r changer le nom d'une fonction si son r�le change). -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se d�sabonner aussi.
