2017-09-08 3 views
0

En utilisant les options de ligne de commande de l'éditeur de liens passées via 'node-gyp', je spécifie le chemin de la bibliothèque et le nom de la bibliothèque que je veux associer au programme. Mais l'exécutable qui en résulte ne fait pas référence au fichier que j'ai spécifié, il fait référence à un nom différent dans /usr/lib. J'utilise la section de bibliothèques dans binding.gyp pour référencer un répertoire local lib.Pourquoi l'éditeur de liens modifie-t-il le nom de la bibliothèque partagée?

 'libraries': [ 
     '-lao-oboe', 
     '-L<(module_root_dir)/lib/', 
     '-Wl,-rpath-link,<(module_root_dir)/lib/', 
     '-Wl,-rpath,<(module_root_dir)/lib/' 
     ], 

node-gyp semble passer les options correctement parce que le retourne linker /usr/bin/ld: cannot find -la-oboe si je change le chemin -L à celui qui ne contient pas libao-oboe.so. L'éditeur de liens renvoie également une erreur si je change le nom de la bibliothèque demandée pour qu'elle soit différente de celle de lib.

Le problème est que la bibliothèque locale ne sera pas chargée lors de l'exécution. ldd montre que le fichier de sortie node-gyp ne fait pas référence au fichier qui a été spécifié - il fait référence à une bibliothèque avec un nom différent - /usr/lib/liboboe-1.0.so.1. Voir la deuxième ligne de ldd sortie:

linux-vdso.so.1 => (0x00007ffee20f5000) 
liboboe-1.0.so.1 => /usr/lib/liboboe-1.0.so.1 (0x00007fa476377000) 
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa475ff5000) 
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa475c2b000) 
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa475a27000) 
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa47580a000) 
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa475501000) 
/lib64/ld-linux-x86-64.so.2 (0x00007fa476922000) 
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa4752eb000) 

Le répertoire de la bibliothèque locale contient:

lrwxrwxrwx 1 bruce bruce  15 Sep 8 02:50 libao-oboe.so -> libao-oboe.so.1` 
-rw-r--r-- 2 bruce bruce 1640848 Aug 31 15:01 libao-oboe.so.1 

Il est vrai que le fichier de la bibliothèque locale, libao-oboe.so.1 est le même que le fichier de bibliothèque de système étant référencé dans l'exécutable (comme indiqué par ldd): /usr/lib/liboboe-1.0.so.1. L'éditeur de liens remarque-t-il d'une manière ou d'une autre que le fichier local est le même (via un hachage ou une signature quelconque) et remplace le fichier de bibliothèque de l'emplacement standard?

Pourquoi le fichier de sortie node-gyp fait-il référence à un fichier de bibliothèque qui n'a jamais été demandé dans le cadre du processus de construction?

+0

Le champ 'soname' du fichier .so finit par remplacer le nom de fichier spécifié dans l'option -l. Je ne comprends pas exactement ce qui se passe, mais si je fais correspondre le nom de fichier au soname, il n'y a pas de problème. – bmacnaughton

Répondre

1

Selon le wikipedia - soname le champ SONAME dans le fichier .so est la "version compatible avec la base". Il ressort du comportement que j'ai trouvé dans le problème ci-dessus que ld insère le SONAME dans le fichier lié à la bibliothèque partagée - pas le nom de fichier spécifié dans la commande ld. Renommer un fichier .so ne modifie pas le SONAME, donc un exécutable lié à un fichier renommé essaiera de charger une bibliothèque nommée par le champ SONAME, pas le nom du fichier.

Ma solution était de ne pas renommer le fichier.