2016-05-27 10 views
-1

Ich lief arm-linux-gnueabihf-ldd auf meine ELF-Dateien (eine von Cygwin - fragen Sie nicht - und eine von Ubuntu), und trotz der Warnungen auf dem Ubuntu eine durch den Einschluss -rpath-Link loszuwerden , die, wie ich annahm, eine dynamische Abhängigkeit statisch machte, angesichts der Mehrdeutigkeit der flüchtigen Manpage, wo ich sie gelesen habe, dll zeigt immer noch ld-linux.so.3 als eines der 5 ungelösten, aber der Linker hat nie über die anderen vier gejammert! Der Pfad war in diesem Fall eine lokale Kopie, die über apt-get installiert wurde.Wo finde ich eine Manpage für arm-linux-gnueabihf-ld, geschweige denn eine gut geschriebene, die -rpath und -rpath-link enthält?

Diese Verschwendung von Zeit verursacht den Host zu beschweren "nicht gefunden" (was bedeutet, wie ich später entdeckte, dass die ELF-Datei gefunden wurde, aber nicht benannte Bibliotheken waren nicht). Die Tatsache, dass der Host-Computer die meisten davon in/lib und den Rest in/usr/lib hat, ließ mich denken, dass -rpath und/oder -rpath-link ihm sagen sollte, wo auf der Host-Maschine nach ihrer Auflösung gesucht werden soll. als ob die Host-Maschine nicht schlau genug ist zu wissen, wo sie Bibliotheken hält.

Ich bin nicht auf der Suche nach etwas "höherer" (dh undurchsichtiger) als einfache arm-linux-gnueabihf-ld Optionen (oder, durch Erweiterung, arm-linux-gnueabihf-g ++ Optionen), die klar sind genug, um in ihrer Verwendung und verursacht keine Meldungen wie:

arm-linux-gnueabihf-g++: error: unrecognized command line option ‘-rpath’ 
arm-linux-gnueabihf-g++: error: unrecognized command line option ‘-rpath’ 

, wenn ich verdammt gut kennen erkannt „-rpath“ in einem anderen Kontext und es beschwert, dass es nicht Wege finden, die nutzlos sind die Host-Maschine, auf der Build-Maschine!

+0

Meinten Sie 'ld' oder' ldd'? –

+0

LDD ist das Dienstprogramm zum Auffinden nicht aufgelöster externer Daten, für die dynamische Bibliotheken erforderlich sind. –

+0

Ich bin mir dessen bewusst, aber Sie schreiben einen im Titel und verwenden einen anderen im Körper Ihrer Frage. –

Antwort

0

Haben Sie versucht man ld?

Die vollständige Dokumentation befindet sich in der binutils manual, die Sie mit info ld lesen können.

-rpath-link, which I assumed was making a dynamic dependency static

Nein, sagt er, den Linker, wo indirekte gemeinsam genutzte Bibliothek Abhängigkeiten zu finden, so dass es ihnen sicher sein, überprüfen Sie, dass es keine ungelösten Referenzen sind.

. The fact that the host machine has most of these in /lib and the rest in /usr/lib made me think that -rpath and/or -rpath-link were supposed to tell it where to look on the host machine for their resolution

Nr

-rpath fügt einen Pfad zur ausführbaren Datei, so dass der dynamische Lader für gemeinsam genutzte Bibliothek Abhängigkeiten in diesem Pfad zur Laufzeit zur Laufzeit aussehen wird. Dies ist eine Möglichkeit, Pfade zu gemeinsam genutzten Bibliotheken anzugeben, lange mit ldconfig, LD_LIBRARY_PATH etc. (Details siehe ld.so(8)).

-rpath-link teilt den Linker mit dem für gemeinsam genutzte Bibliothek Abhängigkeiten suchen bei Link-Zeit, aber keinen Einfluss, wie Abhängigkeiten zur Laufzeit gefunden werden.

Sie können -rpath nicht an g++ übergeben, weil es eine Option für den Linker ist und g++ es nicht versteht. Verwenden Sie -Wl,-rpath, um g++ mitzuteilen, um es an den Linker zu übergeben.

+0

Selbst mit -Wl, "- rpath/lib" -Wl, "- rpath/usr/lib" beschwert es sich immer noch, aber mit der angeblich äquivalenten -Wl, - R/lib "-WL," - R/usr/lib "(was es auch ohne die -Wl akzeptiert), tut es nicht. Es erstellt einfach eine ebenso nutzlose ELF, die keinen Pfad zu den dynamischen Bibliotheken hat, wie immer. –

+0

Die Beanstandung lautet wie folgt: /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: bad - rpath-Option collect2: Fehler: ld gab 1 Exit-Status zurück –

+0

Kann das Problem positionsabhängig sein wie beim Fehlen von Lookahead-Logik beim Auflösen statischer Links? –