Discussion :

[Moskito]

Bonjour à tous!

De ce que j'ai pu lire partout sur le net, le LD_LIBRARY_PATH permet d'indiquer lors de la compil+linking avec g++ (entre autre) où chercher certaines bibliothèques nécessaires à notre linking...

Mon problème vient du fait que j'ai pu également lire que c'était MAL d'utiliser cette variable et qu'il valait mieux utiliser des options du style -L /path -lmaLib.

Et effectivement cela fonctionne bien pour certaines de mes bibliothèques et pas pour d'autres...

Dans mon projet ma ligne de linking ressemble à ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/usr/bin/g++ -L/usr/lib -L/usr/local/python2.6/lib -lpython2.6 /monPath/malib.so -o main main.o

Cette ligne ne me génère pas d'erreur à son exécution.
Par contre, lorsque j'essaye d'exécuter le main généré... j'ai une erreur m'indiquant que la bibliothèque partagée python n'a pu être chargée:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

error while loading shared libraries: libpython2.6.so.1.0: cannot open shared object file: No such file or directory

Il suffit que je rajoute le path vers la lib python dans mon LD_LIBRARY_PATH pour que cela fonctionne... mais je n'arrive pas à comprendre pourquoi, étant donné que je lui indique explicitement ou aller chercher cette bibliothèque. Le mécanisme semblant fonctionner pour l'autre bibliothèque (malib.so) que j'utilise...

Bref, il me manque une brique dans le mur de ma compréhension de tout ça... si quelqu'un l'a à sa disposition, je veux bien qu'il m'éclaire

Merci à tous!

[matafan]

Le -L ne sert qu'au moment de l'édition de lien, pas à l'exécution. L'information n'est pas enregistrée dans le fichier objet produit.

Pour spécifier le "library search path" à utiliser au moment de l'exécution, il faut utiliser l'option -rpath du linker (ld).

[Moskito]

Merci pour cette réponse, elle m'éclaire un peu, mais me fait poser une autre question...

1/A quoi sert l'édition de lien s'il faut repréciser le path vers la librairie au moment de l'exécution?

Pour l'option -rpath, j'ai fait des essais du style:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/usr/bin/g++ -rpath /usr/local/python2.6/lib /monPath/malib.so -o main main.o

...sans résultat, il lui manque toujours des infos apparemment.

Et je viens de lire également que l'uitlisation de rPath n'était pas forcément une bonne idée parceque c'était "en dur" dans la librairie et que du coup il fallait faire attention lors des évolutions etc...

2/C'est quoi la solution optimale finalement: LD_LIBRARY_PATH, rPath, autres?

Encore merci pour votre aide !

[Sve@r]

Merci pour cette réponse, elle m'éclaire un peu, mais me fait poser une autre question...

1/A quoi sert l'édition de lien s'il faut repréciser le path vers la librairie au moment de l'exécution?

L'édition de liens sert
1) si tu utilises des librairies statiques et non dynamique, à rapatrier dans ton exécutable tout le code des librairies que tu utilises
2) dans le cadre de librairies dynamiques, à donner le nom de cette librairie qui sera alors chargée, lors de l'exécution, depuis son emplacement pris à partir de LD_LIBRARY_PATH
3) dans le cas où ton code est éclaté entre plusieurs sources, à relier le code dans l'exécutable

Pour l'option -rpath, j'ai fait des essais du style:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/usr/bin/g++ -rpath /usr/local/python2.6/lib /monPath/malib.so -o main main.o

...sans résultat, il lui manque toujours des infos apparemment.

Et je viens de lire également que l'uitlisation de rPath n'était pas forcément une bonne idée parceque c'était "en dur" dans la librairie et que du coup il fallait faire attention lors des évolutions etc...

2/C'est quoi la solution optimale finalement: LD_LIBRARY_PATH, rPath, autres?

Encore merci pour votre aide !

Je connaissais pas -rpath. Moi je passe toujours par LD_LIBRARY_PATH. Pour moi, s'il y a une variable alors autant s'en servir...

[Moskito]

Merci beaucoup pour ces réponses, c'est désormais plus clair à mes yeux!

[Obsidian]

Sous Linux, il y a aussi /etc/ld.so.conf (et la commande ldconfig) si tes répertoires doivent être visibles par le système entier et installés durablement.

[raphamil]

Les gens de chez suckless déconseillent fortement l'utilisation de bibliothèques dynamiques : moins sécurisé, plus gros, plus lent, plus compliqué

[Sve@r]

Les gens de chez suckless déconseillent fortement l'utilisation de bibliothèques dynamiques : moins sécurisé, plus gros, plus lent, plus compliqué

Moins sécurisé => faudrait qu'ils détaillent ce qu'ils veulent dire par là. Peut-être pensent-ils qu'on peut remplacer une librairie par une autre dénaturant alors le programme qui l'utilise => je répondrais que si les droits sont bien positionnés, faudra se lever tôt pour y arriver. Et dans le cas contraire (pour les accros du chmod 777 au moindre soucis), alors la machine étant open, ça ne sert plus à grand chose d'aller taper dans la librairie...

Plus gros => peut-être. J'ai jamais comparé la taille d'une librairie dynamique et d'une statique

Plus lent => certainement => faut que la librairie soit chargée lors de l'appel. mais est-ce "beaucoup" plus lent ?

Plus compliqué => là non. Si on sait faire alors ça parait simple. C'est comme dans les jeux télévisés: quand on connait la réponse alors la question semble facile...

Sinon j'ai déjà parlé des avantages et inconvénients dans chaque cas...