spec GCC: come ottenere il percorso di installazione

Question

Invece di dare -Wl,-rpath=$HOME/local/gcc52/lib64 ad ogni invocazione di GCC 5.2, che ho costruito dalla fonte, ho modificato il suo file spec in questo modo:

*link_command: 
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S: %(linker) -rpath=%:getenv(HOME /local/gcc52/lib64) ... 

ma questo dipende la mia installazione specifica sotto $HOME/local/gcc52. C'è un modo migliore per riferirsi al percorso di installazione del GCC invocato stesso?

Questa pagina di manuale non mi ha aiutato molto:

• https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html

Answer 1

Per quanto posso dire, GCC è molto dipendente dalla cartella di installazione è stato compilato per. Costruisco molto spesso le toolchain cross-compilation RTEMS e una delle prime cose che ho imparato è che ci sono molti posti nel cross-compilatore generato in cui il prefisso di installazione (cioè qualunque cosa è stato passato a --exec-prefix) è "bruciato" dentro.

"imparato" - come in, ho cercato di spostare la cartella del compilatore in un percorso diverso, e si scatenò l'inferno :-)

il mio punto: la modifica specs file per renderli indicano i percorsi nella vostra installazione sembra assolutamente normale, per quanto riguarda GCC.

Answer 2

Durante la compilazione di GCC, è necessario passare il prefisso desiderato a configure. A quel tempo, puoi anche dargli l'opzione --with-specs. In base ai miei esperimenti, l'opzione --with-specs='%{!static:%x{-rpath='$prefix'/lib64} %x{-enable-new-dtags}}' (dove $prefix should be replaced by the same path you pass to --prefix`) funziona (è necessario qualcosa di più complicato per il supporto multilib, ovviamente).

cose da notare:

• Questo non è ben documentata da nessuna parte, ma sembra che, a differenza di regolare spec files, l'opzione di configurazione --with-specs vale per gli argomenti della riga di comando passati a gcc stesso. Pertanto, non puoi semplicemente provare a modificare la stringa di specifiche *link.
• La sequenza %x non modifica la riga di comando GCC, ma accumula argomenti da passare al linker. Ecco perché passo direttamente allo -rpath e allo -enable-new-dtags invece che tramite -Wl.
• Ci sono un sacco di suggerimenti online su quali specifiche passare. Non l'ho visto da nessuna parte, quindi lo prendo con un pizzico di sale. Il motivo per cui ho usato il mio è che tutti gli altri modificano una stringa di specifiche come, o che non possono essere usate con la riga di comando GCC usando -Wl, che sono abbastanza sicuro che qualcuno abbia detto che hanno avuto problemi con perché in alcuni casi ha confuso GCC quando non stavano collegando. YMMV.
• Se si utilizza il bootstrap (che di solito si è a meno che non si costruisca un cross-compilatore, nel qual caso potrei sbagliarmi ma non penso che questo particolare trucco di rpath sia comunque utile), questo aggiungerà uno RUNPATH ai programmi GCC e anche librerie condivise. Questa sembra essere l'opzione corretta, perché sono stati compilati rispetto alle librerie ora in $prefix/lib64, ma vale la pena notare.

• Ho aggiunto -enable-new-dtags, che inserisce questo valore in DT_RUNPATH anziché DT_RPATH.Questo è l'attributo più recente che dovrebbe essere preferito da tutta la documentazione, <sarcasmo> che è il motivo per cui richiede un flag aggiuntivo che non sia chiaramente referenziato nei documenti </sarcasm >. Tra le differenze tra RPATH e RUNPATH sono:

  • Se RUNPATH è presente, RPATH saranno completamente ignorato.
  • RPATH sovrascrive LD_LIBRARY_PATH; il RUNPATH no.
  • Lavorano in modo differente per le dipendenze di dipendenze (RUNPATH viene cercato solo per le dipendenze dirette; RPATH viene cercato per le dipendenze indirette fintanto che nulla nella catena di dipendenza ha un RUNPATH). Maggiori dettagli sono disponibili here.
  • Penso che sia tutto, ma non sarei sorpreso se mi manca qualcosa.

  Come l'articolo ho linkato sopra indica, non tutti preferisce RUNPATH a RPATH, ma qui non dovrebbe essere un problema a meno che non si mescolano codice da diversi compilatori richiedono diverse librerie di supporto del compilatore in modo complicato, e se si non credo che esista una soluzione valida per tutti.