2013-04-30 19 views
14

Sono un nuovo arrivato a clangore, quindi è probabile che sto facendo qualcosa di stupido. Ma ho passato parecchie ore a cercare soluzioni, inclusa la ricerca qui, dove non ho trovato domande rivolte ai pacchetti forniti con la distro. I dettagli di questa descrizione sono specifici per Fedora 18, ma ho problemi simili su Ubuntu 13.04, quindi il problema non è specifico per Fedora. È o me o clang.L'ottimizzazione del collegamento in tempo clang non funziona correttamente su Fedora 18

Problema: sto cercando di compilare un semplice programma hello-world utilizzando clang++ -flto per ottenere i vantaggi dell'ottimizzazione del tempo di collegamento. Senza -flto funziona bene. Con -flto non riesce a collegare. Invocare come clang -flto -o hello hello.o -v per vedere la linea di comando del linker completa, ottengo:

$ clang++ -flto -o hello hello.o -v 
clang version 3.2 (tags/RELEASE_32/final) 
Target: x86_64-redhat-linux-gnu 
Thread model: posix 
"/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o hello /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../.. -L/lib -L/usr/lib -plugin /usr/bin/../lib/LLVMgold.so hello.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crtn.o 
/usr/bin/ld: /usr/bin/../lib/LLVMgold.so: error loading plugin 
/usr/bin/ld: /usr/bin/../lib/LLVMgold.so: error in plugin cleanup (ignored) 
clang: error: linker command failed with exit code 1 (use -v to see invocation) 

Sembra che ci siano due problemi:

  1. Clang ++ invoca il linker come /usr/bin/ld, e che non è il linker oro. Fedora18 installa oro come /usr/bin/ld.gold. Ho provato a creare un collegamento simbolico da /usr/local/bin/ld a /usr/bin/ld.gold, verificato che which ld dice /usr/local/bin/ld, ma clang ++ non lo usa. Sembra essere cablato a/usr/bin/ld.

  2. clang ++ ha richiamato il linker con -plugin /usr/bin/../lib/LLVMgold.so. È sbagliato, dato che la distribuzione Fedora di clang la colloca a /usr/lib64/llvm/LLVMgold.so.

Ho provato invocare manualmente quella linea linker sopra, con le seguenti modifiche:

  • Sostituire -plugin /usr/bin/../lib/LLVMgold.so con -plugin /usr/lib64/llvm/LLVMgold.so. Ciò restituisce il messaggio di errore hello.o: file not recognized: File format not recognized. Quindi il linker non-gold sembra sapere di plugin, ma non prenderà i file .o che contengono codice bitmap LLVM.

  • Sostituire /usr/bin/ld con /usr/bin/ld.gold. Funziona, genera un eseguibile che viene eseguito come previsto.

  • Entrambi i precedenti con --plugin anziché -plugin. Questo cambiamento non fa differenza.

Quindi qual è il modo migliore per qualcuno che preferisce attenersi ai pacchetti forniti dal sistema per utilizzare clang -flto? Spero che ci sia un file di configurazione, o opzioni non documentate o variabili di ambiente che mi consentiranno di ignorarle. O meglio, che mi manca un pacchetto e un "yum install ..." lo risolverà.

Preferirei non invocare direttamente il linker, poiché i miei makefile devono conoscere gli oggetti e le librerie di sistema di cui ignorare (ad esempio crt1.o, crtbegin.o, crtend.o). Potrei anche creare clang me stesso, ma non vedo nulla nel suo script configure che mi permetta di configurare il percorso del linker e del plugin.

Sto eseguendo Fedora 18. Gli unici pacchetti non distro sul computer sono google chrome e VMware Tools (è un guest all'interno di VMWare Fusion).Le versioni di pacchetti Fedora rilevanti (l'intero computer è "yum aggiornati" a partire da oggi, 29-apr-2013):

$ yum list --noplugins installed binutils* clang* llvm* gcc* 
Installed Packages 
binutils.x86_64      2.23.51.0.1-6.fc18     @updates 
binutils-devel.x86_64    2.23.51.0.1-6.fc18     @updates 
clang.x86_64       3.2-2.fc18       @updates 
clang-devel.x86_64     3.2-2.fc18       @updates 
clang-doc.noarch      3.2-2.fc18       @updates 
gcc.x86_64       4.7.2-8.fc18      @fedora 
gcc-c++.x86_64      4.7.2-8.fc18      @fedora 
llvm.x86_64       3.2-2.fc18       @updates 
llvm-libs.x86_64      3.2-2.fc18       @updates 

risposta

7

C'è un programma di utilità alternatives in Fedora - permette di subtitute un linker con un altro sul sistema livello:

$ sudo alternatives --display ld 
ld - status is auto. 
link currently points to /usr/bin/ld.bfd 
/usr/bin/ld.bfd - priority 50 
/usr/bin/ld.gold - priority 30 
Current `best' version is /usr/bin/ld.bfd. 
$ sudo alternatives --set ld /usr/bin/ld.gold 

Info sulla località LLVMgold.so si può solo segnalare un bug in Fedora Bugzilla, in quanto il percorso è incorporato nelle fonti clang:

lib/driver/Tools.cpp: STD :: string Plugin = ToolChain.getDrive r(). Dir + "/../lib/LLVMgold.so";

I ragazzi Fedora possono applicare una patch al pacchetto sorgente di Clang o creare un collegamento simbolico a LLVMgold.so. Non ci sono ancora cambiamenti anche in Fedora 20.

+5

Solo per risparmiare un po 'di tempo, come potete vedere, sta cercando in 'lib', non in' lib64'. Il link simbolico che ha funzionato per me era 'sudo ln -s /usr/lib64/llvm/LLVMgold.so/usr/lib/LLVMgold.so'. – Jerska

Problemi correlati