[Linker] Problème pour trouver une lib - Page 1

yop,

J'écris un programme qui utilise une lib perso.
J'appelle g++ ainsi, pour linker le programme : /usr/bin/g++ -o ./Debug-unix/editor @"editor.txt" -L/mnt/Data/prog/ng/ngine/Debug-unix/ -lengine
(enfin, c'est l'IDE qui appelle ça)
Comme vous pouvez voir, même en spécifiant le chemin de ma lib en absolu, et alors que engine.so se trouve dans le dossier cible, g++ me dit /usr/bin/ld: cannot find -lengine.
Je suis coincé, le bon chemin et le bon nom, pourtant ça marche pas

Une piste svp ?

Merci d'avance.

-lengine cherche libengine.so, pas engine.so.

Tu cartonnes, merci bien

Ceci dit, je comprends toujours pas, cf ici : https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
(oui oui, j'avais quand même cherché avant de poster)
On y lit ça : -l library Search the library named library when linking

Et ok, sur cette page, j'avais raté la phrase Link -l with library name without the lib prefix and the .a or .so extensions..

Mais du coup, les deux semblent en opposition ?
Qu'est-ce que je rate ??

"without the lib prefix" parce qu'il est rajouté automatiquement.

C'est d'ailleurs pour ça qu'il y a des noms de bibliothèques comme libiberty (à linker avec -liberty), libowfat (à linker avec -lowfat) etc.

Folco (./3) :
Tu cartonnes, merci bien

Ceci dit, je comprends toujours pas, cf ici : https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
(oui oui, j'avais quand même cherché avant de poster)
On y lit ça : -l library Search the library named library when linking

Et ok, sur cette page, j'avais raté la phrase Link -l with library name without the lib prefix and the .a or .so extensions..

Mais du coup, les deux semblent en opposition ?
Qu'est-ce que je rate ??

Sur les anciennes version de gcc (2.8.x par exemple) -lmalib va chercher malib, sur les nouvelles il cherche libmalib

2.8.x, c'était il y a longtemps, mais à ma connaissance, GCC sous GNU/Linux a toujours cherché libmalib.

Kevin Kofler (./7) :
2.8.x, c'était il y a longtemps, mais à ma connaissance, GCC sous GNU/Linux a toujours cherché libmalib.

Possible qu'il y ait eu plusieurs branche de Gcc qui fonctionne différemment ?.


Ce qui est sûr, c'est que mon gcc 2.8.1 (atari) recherche bien malib pour -lmalib

Ça dépend certainement de la plateforme.

Ok, merci beaucoup.
Et comment dire à mon exécutable que la lib dont il a besoin est dans le même répertoire que lui ?
Je suis obligé d'exécuter ldconfig (donc en root), pour spécifier mon répertoire courant ?
Ou alors je dois forcément copier le .so dans /usr/lib ? J'aimerais pas non plus faire des manipulations répétées dans ce répetoire...

Ah, et au passage, comment me permet-on de lancer l'exécution d'une librairie, et comment fait-elle pour segfaulter, vu qu'elle n'est pas censée avoir d'entry point ?folco@Foch:/mnt/Data/prog/ng/ngedit/Debug-unix$ ls editor libngine.so src_main.cpp.o src_main.cpp.o.d folco@Foch:/mnt/Data/prog/ng/ngedit/Debug-unix$ ./libngine.so Segmentation fault
??

ou
export LD_LIBRARY_PATH=.

Et si tu veux pas de LD_LIBRARY_PATH, cf. https://blogs.oracle.com/ali/entry/avoiding_ld_library_path_the
(Bon, perso, je l'utilise depuis des années, et je n'ai toujours pas trouvé le grand "evil" dont ils parlent).

Pour nous chez Fedora, c'est plutôt rpath (l'alternative) qui est "evil".

Merci beaucoup

Un tip pour la librarie qui accepte de s'exécuter ? J'arrive pas à exécuter celle de /usr/lib, par exemple.

Les bibliothèques ne sont pas réellement exécutables, c'est normal. Elles portent le bit exécutable (ce qui fait que le noyau essaie de les exécuter et provoque la faute de segmentation) d'un (du côté de la chaîne d'outils) pour des raisons historiques et de deux (dans les distributions RPM) parce que les scripts qui extraient les informations de débogage pour les paquetages -debuginfo n'opèrent que sur des fichiers marqués exécutables. Mais Debian et dérivées retirent le bit exécutable des bibliothèques exactement pour la raison que tu décris. (Par ici, on est de l'avis que si tu essaies d'exécuter une bibliothèque, c'est ton problème.)

Ok, merci beaucoup. Donc si je voulais rendre ma bibliothèque Debian-compliant, je devrais faire un chmod -x.
Merci bien pour cet éclairage.

Laisse plutôt Debian s'occuper de ça. Pratiquement toutes les autres distributions (qui ne sont pas dérivées de Debian) utilisent +x, et sous Fedora, les bibliothèques doivent être en +x (pour la raison déjà décrite: c'est nécessaire pour les RPMs -debuginfo).

Ok parfait, ça marche.

"the library named library" est stockée dans le fichier liblibrary.so

ok cimer ^^

riende!