Problème de link dynamique

J'ai un problème surement très simple à résoudre, mais mes connaissances sont trop limitées:

j'ai besoin de linker avec un certain nombre de DLLs, qui se trouvent dans un sous répertoire /home/compile/lib/ .
Ce sont des '.so'.

Aucun problème au link, par contre j'ai des problèmes d'éxécution quand je change de machine, en effet, le linker a gardé les liens en dur sur les librairies que j'ai utilisées !

Je pensais qu'en linkant en dynamique, au moment de l'execution le système irai chercher les libs dans /usr/lib/, /usr/var/lib, etc... ou autre répetoire spécifié dans le PATH, mais ce n'est pas le cas.

Code:

---

./test_link: error while loading shared libraries: /home/compile/lib/plouf.so: cannot open shared object file: No such file or directory

---

Donc comment faire pour dire au linker de ne pas prendre les chemins des DLLs en dur ?

Ton programme va chercher dans la variable LD_LIBRARY_PATH la librairie qu il cherche.

Donc sur ta deuxième machine ou sont les librairies dont il a besoin ?
LD_LIBRARY_PATH est setter correctement avec tous les chemins dont il a besoin pour les trouver.
Que donne ld "ton programme" ?
Peux tu donner la ligne de commande du linker ?

J'ai bien setté mon LD_LIBRARY_PATH, voici la ligne correspondante quand je tape 'set':

Code:

---

LD_LIBRARY_PATH=/oracle/10.2/db/lib

---

Les librairies qui me posent problème est une librairie oracle. (libnnz.so).
Les librairies que je spécifie explicitement dans ma ligne de link sont bien résolues (libclntsh.so par exemple)
Par contre la lib qui pose problème est une dépendance de libclntsh.so (qui elle est bien résolue), et apparemment au link il déconne en stockant le path de cette dépendance.

en gros tu link avec libclntsh.so

libnnz.so est une dépendance de libclntsh.so et c est elle qui pose problème.


que donne "ld libclntsh.so" et "ld tonprogramme"
et donne aussi la ligne de link quand tu compile sur ta première machine

Je link actuellement avec gcc.

J'ai essayé d'ajouter l'option -rpath ou -rpath-link pour le problème de lien entre les .so oracle, mais il n'a pas l'air de connaitre cette option. Ca passe en utilisant --rpath, mais j'ai toujours le problème quand je lance ldd sur mon exe.

Voilà ce que fait le linker, j'ai simplifié car il y en a pour 3 pages.

Code:

---

1 2 3 4 5 6

cc -pipe -o /path/vers/mon/exe/test \ [... tous mes .o ...] \ [... plein de libs statiques ...] --rpath /path/vers/mon/rep/de/libs/oracle /path/vers/mon/rep/de/libs/oracle/libclntsh.so [... plein de libs statiques ...] -lnsl -lcrypt -lm -lpthread -ldl

---

J'ai essayé de mettre LD direct pour linker, et j'ai d'autre dépendances de librairies qui ne sont plus trouvées.

pour le linker, les chemins à explorer sont à indiquer par -L chemin. On peut en mettre autant qu'on veut.

Ensuite, il faut indiquer les librairies dans l'ordre de profondeur (si donc une bibliothèque a besoin d'une autre, cette derrière devra être mise après celle qui l'appelle)

Mon problème n'est pas la résolution au link, mais à l'exécution: les librairies qui ne sont pas explicitement utilisées par mon executables ont des liens absolus.

Mon exe utilise directement libclntsh.so, qui elle utilise libnnz.so.

Un ldd de mon exe donne

Code:

---

1 2 3 4 5 6 7 8 9 10

linux-gate.so.1 => (0xffffe000) /path/en/dur/vers/la/lib/libnnz.so => not found libclntsh.so.11.1 => not found libnsl.so.1 => /lib/libnsl.so.1 (0xf7fd0000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x008e8000) libm.so.6 => /lib/tls/libm.so.6 (0xf7fad000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xf7f9b000) libdl.so.2 => /lib/libdl.so.2 (0x009b8000) libc.so.6 => /lib/tls/libc.so.6 (0x007a5000) /lib/ld-linux.so.2 (0x0078b000)

---

Et c'est ça qui me gêne, puisque sur une autre machine, les libs seront pas forcément au meme endroit.

J'ai rempli la variable LD_RUN_PATH pour voir ce que ça donne au link, et c'est pire, puisqu'alors ldd donne ceci sur l'executable:

Code:

---

1 2 3 4 5 6 7 8 9 10

linux-gate.so.1 => (0xffffe000) /path/en/dur/vers/la/lib/libnnz.so => not found /path/en/dur/vers/la/lib/libclntsh.so.11.1 => not found libnsl.so.1 => /lib/libnsl.so.1 (0xf7fd0000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x008e8000) libm.so.6 => /lib/tls/libm.so.6 (0xf7fad000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xf7f9b000) libdl.so.2 => /lib/libdl.so.2 (0x009b8000) libc.so.6 => /lib/tls/libc.so.6 (0x007a5000) /lib/ld-linux.so.2 (0x0078b000)

---

J'ai maintenant les DEUX libs avec des paths en dur !

peux tu dire ou sont les librairies libnnz.so et libclntsh.so.11.1 sur ta deuxième machine ?
Ces paths (sur ta deuxième machine) sont bien settés dans LD_LIBRARY_PATH


Et comme l a dit souviron34, essaie de mettre dans ta ligne de link :

-L/path/vers/mon/rep/de/libs/oracle lclntsh

a la place de

/path/vers/mon/rep/de/libs/oracle /path/vers/mon/rep/de/libs/oracle/libclntsh.so

tu pourras lire avec intérêt la discussion suivante :

http://www.developpez.net/forums/d68...ique-variable/

:mrgreen:

Ashin: meme avec un LD_LIBRARY_PATH bien renseigné, l'exe ne trouve pas les libs, puisque les chemins sont absolus.

Je ne peux pas utiliser 'lclntsh' dans ma ligne de link puisqu'oracle n'est pas installé sur la machine dans les répertoires "standards".

souviron34: j'ai lu le thread, et si je comprends bien, il n'y aucune manière de livrer un executable capable de se linker avec une lib qui n'est pas dans le même répertoire que la machine de compil sans nécessité une intervention sur la machine cible ?

C'est con, pour une fois qu'un truc fonctionne bien sous windows mais pas sous linux. :(

Citation:

---

Envoyé par zifox

souviron34: j'ai lu le thread, et si je comprends bien, il n'y aucune manière de livrer un executable capable de se linker avec une lib qui n'est pas dans le même répertoire que la machine de compil sans nécessité une intervention sur la machine cible ?

C'est con, pour une fois qu'un truc fonctionne bien sous windows mais pas sous linux. :(

---

euh.. ça fonctionne à peu près de la même manière.. il faut mettre ta DLL à un endroit reconnu... C'est en particulier à ça que servent les procédures d'installation de softs... Mais c'est aussi la différence entre un système fermé et un système ouvert... :D

Maintenant, pour unixoides, si, tu peux livrer, si tu livrer les 2 en même temps..

Mais tu peux faire comme on a suggéré dans le fil en question :

• soit faire une bibliothèque statique : ton exécutable est autonome
• soit faire une bibliothèque dynamique et te servir du ldconfig par exemple dans un script de démarrage....
• soit faire une bibliothèque dynamique et que l'arborescence soit la même sur la machine de compil et la machine cible....
• soit faire une bibliothèque dynamique et que elle soit copiée dans /usr/lib....pas d'interventions particulières... Mais c'est quand même mieux et plus sûr à ce compte-là de la mettre aussi là quand tu compiles. Ou bien tu te sers du LD_..PATH

Citation:

---

Envoyé par zifox

Je ne peux pas utiliser 'lclntsh' dans ma ligne de link puisqu'oracle n'est pas installé sur la machine dans les répertoires "standards".

souviron34: j'ai lu le thread, et si je comprends bien, il n'y aucune manière de livrer un executable capable de se linker avec une lib qui n'est pas dans le même répertoire que la machine de compil sans nécessité une intervention sur la machine cible ?

---

si bien sur.
tu as un exécutable delta qui a besoin d'une certaine librairie dynamique. Il va regarder dans LD..PATH si elle y est.
Au besoin tu peux meme changer de version de librairie en rajoutant au début de ton path un endroit ou une meme librairie est aussi présente.


Donc le problème vient de ton link et pas du fait que les librairies ne soient pas au meme endroit sur cette machine. (/path/vers/mon/rep/de/libs/oracle/libclntsh.so)

Oui souviron34 c'est bien ce que j'avais compris, merci. :jap:

J'ai partiellement solutionné mon problème, à l'aide de la technique de sioux que vous avez posté (merci ashin), mettre -lcntsh à la place du ficheir complet, en fait j'avais pas bien compris ce que vous disiez.

J'ai donc mis -L/path/vers/mes/libs, ajouté -lclntsh et -lnnz dans mes libs, et magique, y'a plus les paths en durs ! 8O

J'avoue que je suis content que ca fonctionne, mais je comprends pas pourquoi ça change quelque chose.

si en fait c est un peu comme un include.

la différence entre

#include "/path/vers/mon/rep/de/libs/oracle/libclntsh.h"
et
#include <libclntsh.h>


Dans le premier cas il va pas chercher a comprendre, dans le deuxième il va regarder dans ce qu il a dans sa liste de path pour trouver quelquechose qui correspond

Ah ok, merci.

C'est beaucoup plus clair maintenant ! :king: