Optymalizacja czasu linku w klangie nie działa poprawnie w Fedorze 18

Question

Jestem nowicjuszem, który kłamie, więc prawdopodobnie robię coś głupiego. Ale spędziłem kilka godzin szukając rozwiązań, w tym przeszukując tutaj, gdzie nie znalazłem pytań adresujących -flto z pakietami dostarczanymi przez distro. Szczegóły tego opisu są specyficzne dla Fedory 18, ale mam podobne problemy w Ubuntu 13.04, więc problem nie jest specyficzny dla Fedory. To albo ja, albo klang.

Problem: Próbuję skompilować prosty program do czatu z użyciem clang++ -flto, aby uzyskać korzyści z optymalizacji czasu łącza. Bez fletu działa dobrze. Z -flto nie łączy się. Wywoływanie jak clang -flto -o hello hello.o -v aby zobaczyć pełną linię poleceń łącznika, dostaję:

$ 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) 

Nie wydają się być dwa problemy:

1. Clang ++ wywołuje łącznik jako /usr/bin/ld, a to nie jest łącznik złota. Fedora18 instaluje złoto jako /usr/bin/ld.gold. Próbowałem utworzyć dowiązanie symboliczne od /usr/local/bin/ld do /usr/bin/ld.gold, sprawdziłem, czy which ld mówi /usr/local/bin/ld, ale clang ++ nie używa tego. Wygląda na to, że jest on podłączony do/usr/bin/ld.

2. clang ++ wywołał linker z -plugin /usr/bin/../lib/LLVMgold.so. To źle, ponieważ dystrybucja Clang umieszcza ją pod adresem /usr/lib64/llvm/LLVMgold.so.

Próbowałem ręcznie wywoływania tę linię łącznikową powyżej z następujących poprawek:

• wymienić -plugin /usr/bin/../lib/LLVMgold.so z -plugin /usr/lib64/llvm/LLVMgold.so. Daje to komunikat o błędzie hello.o: file not recognized: File format not recognized. Tak więc nie-złoty linker wydaje się wiedzieć o wtyczkach, ale nie przyniesie plików .o, które zawierają kodek LLVM.

• Wymień /usr/bin/ld na /usr/bin/ld.gold. To działa, generuje plik wykonywalny, który działa zgodnie z oczekiwaniami.

• Oba powyższe z --plugin zamiast -plugin. Ta zmiana nie ma znaczenia.

Jaki jest najlepszy sposób dla kogoś, kto woli trzymać się pakietów dostarczanych przez system, aby użyć flang-flto? Mam nadzieję, że istnieje plik konfiguracyjny lub nieudokumentowane opcje lub zmienne środowiskowe, które pozwolą mi je zastąpić. Albo lepiej, że brakuje mi pakietu i "yum install ..." to naprawi.

Wolałbym nie wywoływać bezpośrednio linkera, ponieważ wtedy moje pliki makefile muszą znać obiekty systemowe i biblioteki, o których powinni wiedzieć (np. Crt1.o, crtbegin.o, crtend.o). Mogłabym też zbudować klang sam, ale nie widzę niczego w swoim skrypcie konfiguracyjnym, który pozwala mi skonfigurować ścieżkę łącznika i wtyczki.

Używam Fedory 18. Jedynymi pakietami niebędącymi dystrybucją na komputerze są google chrome i VMware Tools (jest to gość wewnątrz VMWare Fusion).Wersje odpowiednich pakietów Fedory (cały komputer „yum zaktualizowane” na dzień dzisiejszy 29-kwi-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 

Answer 1

Jest to narzędzie alternatives w Fedorze - umożliwia subtitute jeden łącznik z drugiego na systemie poziom:

$ 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 

O LLVMgold.so miejscu można tylko zgłosić błąd w Fedorze Bugzilla, ponieważ ścieżka jest wbudowany w źródłach dzyń:

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

Faceci z Fedory mogą zastosować poprawkę do pakietu źródłowego Clanga lub utworzyć dowiązanie symboliczne do LLVMgold.so. Nie ma żadnych zmian nawet w Fedorze 20.