Discussion :

[contremaitre]

Bonjour,

Voilà mon problème :
Je voudrais modifier un logiciel (apellons le toto) dont j'ai les sources, et qui à la compilation produit une librairie partagée (libtoto.so)

Mais ce logiciel toto existe également dans mon pc (donc a sa librairie partagée dans /usr/lib/libtoto.so que je voudrai garder pour pouvoir lancer le logiciel original)

Donc pour compiler un programme a moi qui utilise cette librairie que j'ai modifiée, je fait :
gcc -o test test.c -L/chemin_vers_montoto -ltoto

Mais si je lance ./test il va aller cherche libtoto.so dans /usr/lib et non dans /chemin_vers_montoto/libtoto.so

Alors comment faire pour qu'il aille chercher la même librairie qu'à la compilation ?

merci

[contremaitre]

J'ai trouvé deux solutions (je n'ai testé que la première), qui ne sont pas vraiment du ressort du langage C, donc désolé pour le hors sujet, mais comme je compile avec gcc je pensais qu'il pouvait y avoir une solution plus en rapport avec le C ou le compilateur C.

Donc :
Il faut utiliser /lib/ld-linux.so.2 avec l'option --library-path pour lancer le programme.
Sinon on peut aussi modifier LD_LIBRARY_PATH

Ces solutions sont à utiliser bien évidement dans l'optique de debugages ou de développement.

[souviron34]

oui pour une raison logique :

contrairement à une biblothèque statique, où le code de la fonction appelée est recopié dans ton binaire, dans une librairie partagée c'est l'adresse qui est stockée dans ton binaire.

Mais cette adresse est physique : tel chemin + tel fichier + tel offset.

Ce qui fait que normalement, et c'est l'inconvénient majeur des librairies partagées, elles douvent se stiuer exactement au même endroit sur la machine de compilation et d'éxécution.

Grâce à ce flag, tu "bypass" cet inconvénient.

[Médinoc]

c'est l'inconvénient majeur des librairies partagées, elles douvent se stiuer exactement au même endroit sur la machine de compilation et d'éxécution.

C'est une spécificité de nux ?
On n'a pas ce genre de problème sous Windows...

[souviron34]

ben disons que tu as la meme chose (voir les options indiquees par pasdeface).

Mais ce qu'il faut comprendre (et ton pointeur le sous-entend) c'est la maniere dont ca fonctionne..

Et que donc ca ne peut pas etre n'importe ou...

D'ailleurs, ta page montre le chemin par defaut de Windows, et que pour le changer il faut aller changer un REGISTRY...

Ce qui bien entendu n'est franchement pas favorise sous nux...

De plus, le PATH sous nux est pour les binaires, pas les bibliotheques.

Mais ce que je voulais dire, c'est qu'il etait essentiel de comprendre le mecanisme pour comprendre pourquoi ca ne peut pas marcher a tous les coups.

Et d'ailleurs, encore une fois, c'est dans la philosophie Windows et anti-philosophie nux de chercher localement pour une "dll" tierce...