GCC-Spezifikationsdatei: Wie erhält man den Installationspfad?

Soweit ich das beurteilen kann, ist GCC sehr abhängig von dem Installationsordner, für den es kompiliert wurde. Ich habe sehr oft RTEMS-Cross-Compilation-Toolchains erstellt, und eines der ersten Dinge, die ich gelernt habe, war, dass es viele Stellen im generierten Cross-Compiler gibt, wo das Installationspräfix (dh was auch immer an --exec-prefix übergeben wurde) ) ist "verbrannt" in.

"gelernt" - wie in, ich habe versucht, den Ordner des Compilers auf einen anderen Pfad zu verschieben, und die Hölle brach los: -)

Mein Punkt: Das Ändern von specs -Dateien, damit sie auf Pfade in Ihrer Installation zeigen, scheint absolut normal, was GCC betrifft.

Wenn Sie GCC kompilieren, müssen Sie das Präfix, das Sie möchten, trotzdem an co_de% übergeben. Zu diesem Zeitpunkt können Sie auch die Option configure angeben. Basierend auf meinen Experimenten funktioniert die Option --with-specs (wo --with-specs='%{!static:%x{-rpath='$prefix'/lib64} %x{-enable-new-dtags}}' - prefix ') (Sie benötigen natürlich etwas komplizierteres für die Multilib-Unterstützung).

Zu beachten:

• Dies ist nirgendwo richtig dokumentiert, aber es scheint, dass es im Gegensatz zu regulären Spezifikationsdateien , die Option $prefix should be replaced by the same path you pass to configure gilt für die Befehlszeilenargumente, die an GCC selbst übergeben werden. Daher können Sie nicht nur versuchen, die --with-specs -Spezifikationszeichenfolge zu ändern.
• Die *link -Sequenz ändert die GCC-Befehlszeile nicht, sondern akkumuliert Argumente, die an den Linker übergeben werden. Deshalb übergebe ich %x und -rpath direkt anstelle von -enable-new-dtags .
• Es gibt eine Reihe von Vorschlägen online für welche Spezifikationen zu übergeben sind. Ich habe das nirgendwo gesehen, also ist es mit einem Körnchen Salz. Der Grund, warum ich meine eigene verwendet habe, ist, dass alle anderen entweder einen Spezifikationsstring wie -Wl modifizieren, was mit *link nicht möglich ist, oder sie fügen Optionen zur GCC-Befehlszeile mit --with-specs hinzu, was ziemlich sicher ist Jemand sagte, dass sie Probleme hätten, weil es in einigen Fällen GCC verwirrte, wenn sie nicht verlinkten. YMMV.
• Wenn Sie Bootstrapping verwenden (was Sie normalerweise sind, wenn Sie keinen Cross-Compiler erstellen, in welchem ​​Fall ich falsch liegen könnte, aber ich denke nicht, dass dieser spezielle rpath-Trick trotzdem nützlich ist), fügt dies -Wl hinzu GCC-Programme und gemeinsam genutzte Bibliotheken. Dies scheint die richtige Option zu sein, da sie gegen die Bibliotheken in RUNPATH kompiliert wurden, aber es ist erwähnenswert.

• Ich habe $prefix/lib64 hinzugefügt, was in -enable-new-dtags statt in DT_RUNPATH steht. Dies ist das neuere Attribut, das laut der gesamten Dokumentation bevorzugt werden sollte, & lt; sarkasm & gt; weshalb es ein zusätzliches Flag erfordert, das in der Dokumentation & lt; / sarkasm & gt; nicht eindeutig durch Querverweisen gekennzeichnet ist. Zu den Unterschieden zwischen RPATH und RUNPATH gehören:

  • Wenn RUNPATH vorhanden ist, wird RPATH komplett ignoriert.
  • Der RPATH überschreibt DT_RPATH ; der RUNPATH nicht.
  • Sie arbeiten etwas anders für Abhängigkeiten von Abhängigkeiten ( LD_LIBRARY_PATH wird nur nach direkten Abhängigkeiten durchsucht; RUNPATH wird nach indirekten Abhängigkeiten durchsucht, solange nichts in der Abhängigkeitskette ein RPATH hat). Weitere Details finden Sie hier .
  • Ich denke, das ist alles, aber ich wäre nicht überrascht, wenn ich etwas verpasse.

  Da der Artikel, den ich oben verlinkt habe, nicht alle RUNPATH zu RPATH vorzieht, sollte das hier kein Problem darstellen, außer du mischst Code aus verschiedenen Compilern, die auf komplizierte Weise verschiedene Compiler-Support-Bibliotheken benötigen, und wenn du das tust glaube nicht, dass es eine Einheitslösung gibt.