Discussion :

[BioKore]

Bonjour à tous,


Apprenant actuellement le C++ tout en réalisant de petits projets persos, j'en vient à essayer de simplifier un peu mes programmes utilisant des classes communes. Par exemple, j'ai réalisé une classe permettant de réaliser des calculs sur des vecteurs (cross products, distances entre deux points etc...), qui doit pouvoir être utilisée dans au moins deux de mes programmes (et plus à venir).

Bien que ma classe zvector (oui c'est comme ça que je l'ai nomée...) soit loin d'être finalisée et nécessite d'être améliorée sur plusieurs points, j'en ai néanmoins besoin pour tester mes différents programmes. J'ai donc pensé à en faire une librairie dynamique, ce qui me permettrait de voir directement l'impact des modification de cette dernière sur les programmes l'utilisant.

Mais voilà le problème : je n'en ai jamais fait ! Aussi je pensais que cela serait "simple" (en tout cas, l'idée ne me parait pas compliquée) mais je galère tout de même.

Voici, pour mes premiers essais, le processus de compilation utilisé :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
 
# création du zvector.o avec -fPIC :
g++ -W -Wall -Werror -Wextra -O6 -fPIC -c zvector.cpp
 
# création du zvector.so en partagé :
g++ -shared -o zvector.so zvector.o
 
# essai de compilation d'un programme quelconque avec linkage du zvector.so
g++ -W -Wall -Werror -Wextra -O6 -L$(ZVECT_LIB_PATH) main.cpp zvector.so -o zvect.ex

Bon, les options de compilation ne sont pas les définitives (les -W -Wall -O6 etc...) et sont inutiles sur la dernière ligne je pense, mais comptant passer, par la suite par un makefile, je referais tout ça à l'occasion.

Le processus ci-dessus me sort donc bien un zvector.so et un zvect.ex. Seulement, lorsque j'exécute le zvect.ex, j'obtient l'erreur suivante :

Code :

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

./zvect.ex: error while loading shared libraries: zvector.so: cannot open shared object file: No such file or directory

Première idée qu'il me vient, c'est que le .so n'est pas dans les dossiers /usr/lib ou autre... Cependant, je souhaiterais conserver le .so dans le dossier de l'exécutable. J'ai donc bien pensé à faire un lien symbolique. Cependant, je n'aime pas l'idée de venir bidouiller / modifier les dossiers systèmes avec des fichiers que je ne penserais pas à supprimer quand je n'en aurais plus l'utilité.

Mes questions sont donc les suivantes :

- Mon processus est-il correcte ?
- y a t'il un moyen de dire à l'exécutable de venir chercher dans son dossier avant d'aller chercher dans les dossiers systèmes ?

Je précise aussi que mon code (les *.cpp) ne sont absolument pas modifié. Je les ai codés exactement comme si je compilais exécutable en direct. Peut-être est-ce là aussi un problème ?

EDIT : j'ai lu aussi le "tuto" présent ici (yolinux) mais je ne comprends pas l'idée de faire plusieurs liens, avec des .so.1.0 et .so.1 etc...



D'avance, merci pour vos retours !

[BioKore]

Je vois que ce type de question n'attire pas les foules....

Néanmoins, j'ai pu faire d'autres essais fructueux. Mon *.so est bien valide et j'arrive à la linker avec l’exécutable, peu importe où se trouve la bibliothèque. C'est déjà une bonne chose. Cependant, il y a un petit truc que je n'arrive pas à comprendre. Lorsque je link sur un programme tiers (un .cpp quelconque utilisant la librairie) avec la commande suivante :

Code :

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

g++ main.o -o tst.ex -L ./lib -ltestlib

j'ai bien une création de l’exécutable sans erreur, mais lorsque je lance le programme, la console me dit qu'il est impossible de trouver le .so :

Code :

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

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

Par contre, si je compile avec la commande suivante :

Code :

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

g++ main.o -o tst.ex lib/libtestlib.so

là je n'ai aucun souci. Je trouve ce retour assez étrange. Une idée de l'origine de mon erreur ?

Je tiens à préciser que le nom de la librairie est bien "libXXX.so, donc je peux utiliser l'option -lXXX (de toutes façons s'il y avait un problème avec le nom, le linker me cracherais une belle erreur j'imagine).



Merci d'avance !

[LittleWhite]

Bonjour,

Vous pouvez régler le problème du chargement du .so, en utilisant la variable LD_LIBRARY_PATH :

LD_LIBRARY_PATH=./lib ./tst.ex

Ainsi, le programme, qui utilise la variable, trouvera le .so.

Toutefois, il y a mieux : l'option -rpath pour ld.

[BioKore]

Bonjour,

Un peu en retard sur ma réponse, mais je suis sur trop de sujets en parallèle. Désoler...

Mais merci pour ce retour. Je vais voir ce qu'il en est pour l'option -rpath (j'ai un peu du mal à comprendre le MAN de cette option).
Sinon, oui, je peux passer par la variable globale LD_LIBRARY_PATH, j'avais déjà essayé mais malgré ça, j'avais une erreur similaire (je ne me souviens plus trop).

Je vais me remettre dedans pour voir. Pour le moment, je peux me contenter de mettre les chemins entiers mais bon, je pense que je vais rapidement avoir besoin de quelque chose de plus perin.


Merci.