Wie kompiliere LLVM gegen eine benutzerdefinierte glibc?

Ich benutze YouCompleteM Vim-Plugin für Textvervollständigung (installiert über Vundle ). YouCompleteMe verwendet Clang für Textvervollständigung für C-Familiensprachen (C, C ++, Objective-C, Objective-C ++). Nach der Aktualisierung von YouCompleteM (über :VundleUpdate in Vim) funktioniert YouCompleteM nicht mehr.

Kurz gesagt, lautet die Frage: Wie kann ich Clang gegen eine benutzerdefinierte glibc-Version kompilieren? Debian Wheezy wird mit glibc 2.13 ausgeliefert und es scheint, dass die neueste Clang-Version mindestens glibc 2.15 (Erklärung in mehr Detail unten). Nur für den Fall, ich benutze Debian Wheezy, x86-64 und eine benutzerdefinierte Linux-Kernel-Version 4.0.0-rc6.

Also habe ich LLVM aus dem Git-Spiegel nach den Anweisungen auf der LLVM-Website heruntergeladen:

%Vor%

Dann habe ich LLVM nach den Anweisungen auf der LLVM-Website kompiliert :

%Vor%

Alles in Ordnung, also habe ich mit der YouCompleteMe-Installation fortgefahren, indem ich die YouCompleteMe-Unterstützungsbibliotheken nach YouCompleteMe-Installationsanweisungen :

%Vor%

Dann lief ich Vim und ich bemerkte, dass YouCompleteMe immer noch nicht zu funktionieren scheint. Wenn ich den Bearbeitungsmodus in Vim in einer C ++ Datei (zum Beispiel) betrete, druckt YouCompleteMe Fehler: The ycmd server SHUT DOWN (restart with :YcmRestartServer). Stderr (last 30 lines): , und danach :YcmRestartServer druckt Restarting ycmd server... , dann ('Connection aborted.', error(111, 'Connection refused')) ).

:YcmDebugInfo gibt Folgendes aus:

%Vor%

/tmp/ycm_temp/server_37730_stdout.log ist leer, aber /tmp/ycm_temp/server_37730_stderr.log enthält die folgenden Zeilen:

%Vor%

Ich habe also die Tests von YouCompleteMe ausgeführt und diesen Fehler erhalten, als ich ./vim/bundle/YouCompleteMe/third_party/ycmd/run_tests.sh :

ausgeführt habe %Vor%

So scheint es, dass Clang 3.6.0 glibc 2.15 oder neuer benötigt. Debian Wheezy wird mit glibc 2.13 ausgeliefert. Also entschied ich mich für die neuste stabile Version von glibc (aktuell 2.21). Ich hatte bereits zuvor binutils kompiliert und in /usr/local/bin/ installiert, also musste ich das jetzt nicht machen.

Also habe ich Ссылка heruntergeladen und dann entpackt und die Quelle kompiliert und installiert :

%Vor%

Dann habe ich LLVM neu kompiliert. Ich übergab in CMAKE_CXX_FLAGS Umgebungsvariable die g ++ Linker Flags an cmake folgende Antwort von Employee Russian auf SO Frage Mehrere glibc-Bibliotheken auf einem einzelnen Host :

%Vor%

Und dann habe ich die YouCompleteMe-Unterstützungs-Bibliotheken neu kompiliert und erneut g ++ Linker-Flags an cmake in CMAKE_CXX_FLAGS :

übergeben %Vor%

Aber das Problem mit YouCompleteM bleibt bestehen und Tests schlagen immer noch auf die gleiche Weise fehl. Vielleicht ist CMAKE_CXX_FLAGS keine ausreichende Möglichkeit, g ++ Linker-Flags an cmake zu übergeben? Ich versuchte auch, LD_LIBRARY_PATH zu verwenden, wenn ich LLVM gegen glibc 2.21 kompiliere:

%Vor%

Und habe diesen Fehler:

%Vor%

Dann habe ich auch LD_PRELOAD :

ausprobiert %Vor%

Und habe diese Fehler:

%Vor%

Dann habe ich auch versucht, /usr/local/glibc/glibc-2.21/lib/ld-2.21.so zu export LD_PRELOAD hinzuzufügen, aber es hat die Fehlermeldung in keiner Weise verändert.

Ich bin mir ziemlich sicher, dass Clang glibc 2.15 (exact) nicht benötigt, auch wenn das andere fehlende Symbol ( posix_spawn@GLIBC_2.15 ) ursprünglich aus glibc 2.15 stammt, da glibc gemäß seiner Dokumentation versucht, Rückwärtskompatibilität zu wahren, und trotzdem das andere fehlendes Symbol ( memcpy@GLIBC_2.14 ) stammt von glibc 2.14. Also habe ich das alles nicht mit Glibc 2.15 probiert. Aber jetzt habe ich keine Ideen mehr und jeder Rat wäre willkommen.

Bearbeiten 1

Ich folgte Employeed Russian's answer (unten) , aber mein Problem hat sich in keiner Weise geändert. Also kam ich zu dem Schluss, dass export CMAKE_CXX_FLAGS nicht der richtige Weg ist, g ++ Linker Flags an cmake zu übergeben. CMAKE_CXX_FLAGS ist der Name einer Variablen intern bis cmake , aber cmake interessiert sich überhaupt nicht für eine Umgebung Variable mit demselben Namen ( CMAKE_CXX_FLAGS ). CMAKE_CXX_FLAGS kann direkt in CMakeLists.txt definiert werden, aber in LLVM-Kompilieranweisungen Kein Master CMakeLists.txt wird verwendet und ich möchte das LLVM-Kompilierungsscript nicht von Grund auf neu erstellen, wenn es eine praktikablere Option gibt. Aber es gibt noch 3 andere Möglichkeiten, die ich finden konnte:

1. cmake initialisiert CMAKE_CXX_FLAGS von einer Umgebungsvariablen namens CXXFLAGS . Siehe sakras Antwort auf SO Frage Hinzufügen von Verzeichnissen zu cmake beim Aufruf von der Befehlszeile aus .

%Vor%

2. CMAKE_CXX_FLAGS kann auch über die Befehlszeile mit -DCMAKE_CXX_FLAGS :
initialisiert werden

%Vor%

3. CMAKE_CXX_FLAGS kann auch mit -DCMAKE_CXX_FLAGS:STRING von der Befehlszeile aus initialisiert werden (siehe Build mplllibs ):

%Vor%

Alle diese 3 Optionen ergeben genau das gleiche Ergebnis: das Kompilieren von LLVM endet mit demselben Fehler, der mit den Zielen llvm-tblgen und intrinsics_gen zusammenhängt (die einzigen Unterschiede zwischen den 3 Makefile , die oben von% co_de erzeugt wurden % Befehle befinden sich in Verzeichnisnamen, verursacht durch die Tatsache, dass jeder Build in einem anderen Verzeichnis erstellt wurde). Es scheint, dass das Ziel cmake entsprechend kompiliert und verknüpft wird, aber danach scheint das Ziel llvm-tblgen eine Abhängigkeit vom Ziel llvm-tblgen zu sein, und irgendwie kann intrinsics_gen nicht gefunden werden. Dies sind die letzten Zeilen der Ausgabe von llvm-tblgen (diese sind für jede der 3 obigen Builds identisch):

%Vor%

Ich frage mich, ob das, wenn dies ein Fehler in LLVM ist oder make variable cmake so wie ich es getan habe (in den 3 Builds oben) ausreichend ist oder dies durch etwas anderes verursacht wird. Irgendwelche Ideen, wie man fortfährt, würde sehr geschätzt werden.

Bearbeiten 2

Wie von Employeed Russian in seinem Kommentar vorgeschlagen ( unter seiner Antwort ):

%Vor%

Dies verursachte auch einen Kompilierungsfehler in Bezug auf die Ziele CMAKE_CXX_FLAGS und llvm-tblgen , aber der Fehler war anders als beim vorherigen Fehler. Dies sind die letzten Zeilen von intrinsics_gen output:

%Vor%

So scheint es, dass make jetzt gefunden wird, aber es gibt einen Fehler beim Laden der shared library llvm-tblgen . Also habe ich libtinfo.so.5 in --rpath=/usr/local/glibc/glibc-2.21 geändert und es erneut versucht:

%Vor%

Diese Änderung von --rpath=/usr/local/glibc/glibc-2.21/lib hat jedoch die von --rpath erzeugte Fehlermeldung überhaupt nicht geändert. Ich frage mich, wo diese gemeinsame Bibliothek make gefunden werden sollte.

Dann habe ich die Clang + LLVM-Compiler-Website erstellt und versucht, libtinfo.so.5 zu -std=c++11 hinzuzufügen. :

%Vor%

Aber es hat nicht geholfen, die Fehlermeldung ist identisch, das heißt, die gemeinsam genutzte Bibliothek CXXFLAGS kann immer noch nicht gefunden werden. Vielleicht ist meine libtinfo.so.5 Version zu alt, es ist g++ 4.7.2, die mit Debian Wheezy ausgeliefert wird ( g++ prints g++ --version ). Der Autor von Erstellen der Clang + LLVM-Compiler-Website schreibt, dass er versucht hat, LLVM unter Fedora 15 nur mit% zu erstellen. co_de% 4.7.1 ist fehlgeschlagen, wobei das Kompilieren mit mehreren Neustarts mit verschiedenen g++ (Debian 4.7.2-5) 4.7.2 Versionen (4.8, 4.8.0, 4.7.1) erfolgreich war (beschrieben auf der Webseite). Irgendwelche Ideen?

Bearbeiten 3

Wie von Employeed Russian vorgeschlagen, habe ich glibc 2.21 mit g++ :

neu kompiliert %Vor%

g++ hat einige Fehler verursacht:

%Vor%

Wie auch immer, ich habe das neu kompilierte glibc 2.21 installiert:

%Vor%

-Wl,--rpath=/usr/local/glibc/glibc-2.21/lib:/lib:/usr/lib:/lib/x86_64-linux-gnu hat diese Warnung erzeugt:

%Vor%

Dann habe ich LLVM erneut mit: make check :

neu kompiliert %Vor%

Aber make install fehlte:

%Vor%

Also kam ich zu dem Schluss, dass es noch ein anderes Bibliotheksverzeichnis geben muss, das für -Wl,--rpath=/usr/local/glibc/glibc-2.21/lib:/lib:/usr/lib:/lib/x86_64-linux-gnu benötigt wird.

%Vor%

Von diesen scheint libstdc++.so.6 am geeignetsten für mich zu sein. Also habe ich --rpath zu ./lib/x86_64-linux-gnu/libstdc++.so.6 hinzugefügt und glibc 2.21 noch einmal neu kompiliert:

%Vor%

Ich habe mich dieses Mal nicht um /usr/lib/x86_64-linux-gnu bemüht, sondern direkt mit der Installation fortgefahren:

%Vor%

Und habe die gleiche scheinbar harmlose Warnung:

%Vor%

Also habe ich --rpath zu make check für LLVM hinzugefügt und LLVM neu kompiliert:

%Vor%

Der Build war erfolgreich, also habe ich LLVM installiert:

%Vor%

Dann habe ich YouCompleteMe-Support-Bibliotheken mit dem gleichen /usr/lib/x86_64-linux-gnu , das ich zum Kompilieren von LLVM verwendet habe, neu kompiliert:

%Vor%

Dieser Build war auch erfolgreich. Dann habe ich YouCompleteMe neu installiert:

%Vor%

Die Fertigstellung scheint zu funktionieren. Dann habe ich die Tests von YouCompleteMe durchgeführt:

%Vor%

OK, Fertigstellung funktioniert noch.

%Vor%

Dies verursachte ein Problem. Es sieht so aus, als ob diese --rpath Support-Bibliotheken neu kompiliert - ohne meine CXXFLAGS zu benutzen - und deshalb die Support-Bibliotheken zerstört. Lösung ist nicht , um .vim/bundle/YouCompleteMe/third_party/ycmd/run_tests.sh auszuführen.

%Vor%

Also habe ich die Support-Bibliotheken genauso neu kompiliert, wie ich es kürzlich gemacht habe, und YouCompleteMe erneut installiert:

%Vor% %Vor%

Und schließlich funktioniert YouCompleteMe wieder!