2017-09-14 3 views
4

Je suis en train de construire une bibliothèque d'objets partagés sur Debianla construction d'une bibliothèque d'objets partagés: ldd ne montre pas le nom spécifié

cat /etc/issue 
Debian GNU/Linux 9 \n \l 

Je construis la bibliothèque et de l'objet comme normal (wrap.c sert de wrapper pour créer tous les fichiers objets)

gcc -c -fPIC -W -Wall -O2 -funroll-loops wrap.c 
gcc -shared -Wl,-soname,libtest.so -o libtest.so *.o 
mv libtest.so /usr/local/lib/ && mv test-header.h /usr/local/include/ 

je crée alors un test.c pour tirer dans la bibliothèque et compilera comme suit:

gcc test.c -ltest

Cependant, l'exécution du programme ./a.out renvoie l'erreur suivante:

./a.out: error while loading shared libraries: libtest.so: cannot open shared object file: No such file or directory

le .so Inspecter, je vois:

$ ldd /path/to/libtest.so 
    linux-vdso.so.1 (0x00007ffdb71c5000) 
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1c22fba000) 
    /lib64/ld-linux-x86-64.so.2 (0x00007f1c23560000) 

Je ne vois même pas libtest.so => none, dont au moins raconterait moi, il ne peut pas trouver la bibliothèque.

Je ne suis pas vraiment sûr de ce qui se passe ici.

Je dois créer avec succès un .dylib sur macOS avec le même processus (avec gcc -dynamiclib -o libtest.dylib *.o), et je peux appeler avec succès la bibliothèque dans un exécutable. Je ne suis pas sûr de ce qui est différent sur Debian.

Répondre

2

La bibliothèque partagée libtest.so que vous avez placé dans /usr/local/lib sera situé par linker dans la commande

gcc test.c -ltest 

parce /usr/local/lib est une recherche par défaut de l'éditeur de liens chemins.

Cependant, il pas se trouver là par le moteur d'exécution chargeur lorsque vous essayez d'exécuter ./a.out parce que le temps d'exécution chargeur ne recherche pas les répertoires directement autres que ceux qui sont énumérés dans la valeur de la LD_LIBRARY_PATH variables, le cas échéant , dans l'environnement actuel. Par défaut, il recherche les bibliothèques enregistrées dans le cache ldconfig , et ce cache est mis à jour pour enregistrer les nouvelles bibliothèques apparues uniquement en exécutant ldconfig (en tant que root).

Donc, pour exécuter votre programme, vous avez deux options: -

Pour réussir dans votre shell en cours, exécutez:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib; ./a.out 

Pour un succès durable, exécutez:

sudo ldconfig 

Ensuite, votre le programme fonctionnera dans n'importe quel shell.BTW, ldd /path/to/libtest.so vous indique, bien sûr, les dépendances de bibliothèque partagée de libtest.so. Ce n'est pas va vous dire pourquoi courir ./a.out échoue à trouver /path/to/libtest.so lui-même. Pour voir les dépendances de bibliothèques partagées de a.out, exécutez ldd a.out

+1

Je vous recommande de définir [rpath] (https://en.wikipedia.org/wiki/Rpath) au moment de la liaison avec '-Wl, -rpath,/usr/local/lib' –

+0

@Mike Kinghan Doh ....! J'ai complètement pété le cerveau que j'utilisais ldd sur la bibliothèque plutôt que sur l'exécutable. Pour une raison quelconque, cela m'a complètement égaré. Appréciez la perspicacité! – floopy