Dans une édition de lien d'un exécutable, il est possible d'utiliser l'option :

-Wl,-rpath <Chemin_des_librairies_dynamiques_à_utiliser>

qui permet justement de s'affranchir de l'initialisation de LD_LIBRARY_PATH.

Maintenant, le chemin "/usr/lib" est tellement inhérent à tous les systèmes Unix et donc à GNU/Linux, cela ne m'étonnerait pas que l'éditeur de lien l'utilise implicitement.

Remarque : Moins il y a de chemins définis dans LD_LIBRARY_PATH, moins il y a de risque de "collisions", de symboles mal définis en type ou carrément des signatures de méthodes qui feront planter l'exécutable car l'ordre de définition de ces chemins peut devenir un vrai casse tête. Une LD_LIBRARY_PATH vide est l'idéal que les développeurs devraient avoir à l'esprit.

Cordialement, A+
--
Claudius

/usr/lib fait partie des répertoires standards pour chercher les bibliothèques donc ça fonctionne.

Petite question sur la variable d'environnement LD_LIBRARY_PATH :

Je lance mon programme exampledyn construit simplement pour me familiariser avec la construction de librairies, qui utilise libarith.so qui est situé dans le répertoire de lancement.

fa@fa:~/HDE_TESTS/MATHS$ ./exampledyn
./exampledyn: error while loading shared libraries: libarith.so: cannot open shared object file: No such file or directory

J'affiche le contenu de ma variable LD_LIBRARY_PATH :

fa@fa:~/HDE_TESTS/MATHS$ echo $LD_LIBRARY_PATH

fa@fa:~/HDE_TESTS/MATHS$ 

La variable LD_LIBRARY_PATH est vide.
je place ma librairie libarith.so dans /usr/lib
Je relance mon programme ... ça marche. Pourquoi ça marche puisque LD_LIBRARY_PATH est vide ?

Merci