2017-09-08 8 views
0

Verwenden von Linker-Befehlszeilenoptionen, die über 'node-gyp' übergeben werden Ich gebe den Bibliothekspfad und den Bibliotheksnamen an, mit dem das Programm verknüpft werden soll. Die resultierende ausführbare Datei verweist jedoch nicht auf die angegebene Datei. Sie verweist auf einen anderen Namen in /usr/lib.Warum ändert der Linker den Namen der gemeinsam genutzten Bibliothek?

Ich verwende den Abschnitt Bibliotheken in binding.gyp, um auf ein lokales Verzeichnis lib zu verweisen.

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

node-gyp scheint die Optionen richtig zu vorbei, da der Linker /usr/bin/ld: cannot find -la-oboe zurück, wenn ich den -L Weg zu einem ändern, die nicht libao-oboe.so enthält. Der Linker gibt auch einen Fehler zurück, wenn ich den Namen der angeforderten Bibliothek anders als die in lib ändern.

Das Problem ist, dass die lokale Bibliothek zur Laufzeit nicht geladen wird. ldd zeigt, dass die Ausgabedatei nicht die angegebene Datei referenziert - es verweist auf eine Bibliothek mit einem anderen Namen insgesamt - /usr/lib/liboboe-1.0.so.1. Siehe die zweite Zeile von ldd Ausgabe:

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) 

Das lokale Bibliotheksverzeichnis enthält:

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 

Es ist der Fall, dass die lokale Bibliotheksdatei, libao-oboe.so.1 das gleiche wie die Systembibliothek Datei wird verwiesen die ausführbare Datei (wie gezeigt durch ldd): /usr/lib/liboboe-1.0.so.1.

Erkennt der Linker irgendwie, dass die lokale Datei die gleiche ist (über Hashing oder eine bestimmte Signatur) und die Bibliotheksdatei vom Standardspeicherort ersetzt?

Warum verweist die Ausgabedatei node-gyp auf eine Bibliotheksdatei, die nie als Teil des Erstellungsprozesses angefordert wurde?

+0

Das Feld 'soname' in der .so-Datei ersetzt den in der Option -l angegebenen Dateinamen. Ich verstehe nicht genau, was passiert, aber wenn ich den Dateinamen mit dem Soname übereinstimme, dann gibt es kein Problem. – bmacnaughton

Antwort

1

Gemäß wikipedia - soname ist das SONAME-Feld in der Datei .so die "base-kompatible Version". Aus dem oben im Problem gefundenen Verhalten geht hervor, dass ld den SONAME in die Datei einfügt, die mit der gemeinsam genutzten Bibliothek verknüpft ist - nicht der im Befehl ld angegebene Dateiname.

Durch das Umbenennen einer .so Datei wird das SONAME nicht geändert, sodass eine ausführbare Datei, die mit einer umbenannten Datei verknüpft ist, versucht, eine vom SONAME-Feld benannte Bibliothek und nicht den Dateinamen zu laden.

Meine Lösung war, die Datei nicht umzubenennen.

Verwandte Themen