Kompilierung schlägt fehl mit “Relocation R_X86_64_32 gegen `.rodata.str1.8′ kann nicht verwendet werden, wenn ein gemeinsames Objekt erstellt wird”
Lesezeit: 6 Minuten
Benutzer1667191
Ich versuche, diesen Quellcode aus dem Makefile in einem VPS zu kompilieren, aber es funktioniert nicht. Der VPS ist ein 64-Cent-Betriebssystem
Hier ist der vollständige Fehler
# make
gcc -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/amx/*.c
g++ -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/*.cpp
g++ -c -O3 -w -DLINUX -I../SDK/amx/ *.cpp
g++ -O2 -fshort-wchar -shared -o "TCP_V1.so" *.o
/usr/bin/ld: TCP-LINUX_V1.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
TCP-LINUX_V1.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [all] Error 1
Tut mir leid, aber ich bin mir nicht sicher, wie ich das machen soll. Kann bei Google nichts über “-fPIC” finden.
– Benutzer1667191
14. Oktober 13 um 16:49 Uhr
Versuchen Sie so etwas wie COMPILE_FLAGS=-c -O3 -w -DLINUX -fPIC -I../SDK/amx/
– Joachim Isaksson
14. Oktober 13 um 17:05 Uhr
Siehe auch: stackoverflow.com/questions/6093547/…
– Ciro Santilli 新疆再教育营六四事件法轮功郝海东
22. Oktober 15 um 20:16 Uhr
Wenn Sie bei Google nach -fPIC suchen, werden Sie sicherlich nichts finden. Entfernen Sie das Minus oder verwenden Sie Anführungszeichen “-fPIC”, sonst lassen Sie alle Ergebnisse weg, die fPIC enthalten.
– d00d
7. Juli 17 um 7:49 Uhr
Alexander Schukajew
Tun Sie, was der Compiler Ihnen sagt, dh neu kompilieren mit -fPIC. Um zu erfahren, was dieses Flag tut und warum Sie es in diesem Fall brauchen, siehe Codegenerierungsoptionen des GCC-Handbuchs.
Kurz gesagt, der Begriff Positionsunabhängiger Code (PIC) bezieht sich auf den generierten Maschinencode, der speicheradressenunabhängig ist, dh keine Annahmen darüber trifft, wo er in den RAM geladen wurde. Nur positionsunabhängiger Code soll in gemeinsam genutzte Objekte (SO) aufgenommen werden, da sie in der Lage sein sollten, ihre Position im RAM dynamisch zu ändern.
Schließlich können Sie darüber weiterlesen Wikipedia auch.
Können Sie erklären, wie Sie mit -fPIC neu kompilieren?
– Beni Bogosel
10. September 14 um 18:10 Uhr
@Beni Bogosel: Das ist ganz einfach. Sie fügen einfach die hinzu -fPIC zu allen Compiler-Aufrufen für alle Quelldateien (Übersetzungseinheiten, z *.cpp Dateien) der Bibliothek. Die konkrete Vorgehensweise hängt von dem von Ihnen verwendeten Build-System ab. In CMake könnten Sie beispielsweise ausgeben set_target_properties(${LIBRARY_NAME} PROPERTIES POSITION_INDEPENDENT_CODE ON). Im Falle dieses Typen (mit dem einfachen alten Make) müsste er es tun COMPILE_FLAGS+=-fPIC da er diese Variable verwendet, um den Satz von Kompilierungs-Flags für alle Quelldateien seiner Bibliothek zu bezeichnen.
– Alexander Schukajew
11. September 14 um 6:46 Uhr
um -fPIC mit configure zu aktivieren: configure –enable-shared, siehe stackoverflow.com/a/850464/440403
– Camino
26. Januar 19 um 3:05 Uhr
XavierStuvw
In meinem Fall trat dieser Fehler auf, weil a make Befehl erwartete, gemeinsam genutzte Bibliotheken abzurufen (*.so Dateien) aus einem entfernten Verzeichnis, das durch a gekennzeichnet ist LDFLAGS Umgebungsvariable. Dort waren fälschlicherweise nur statische Bibliotheken verfügbar (*.la oder *.a Dateien).
Daher lag mein Problem nicht bei dem Programm, das ich kompilierte, sondern bei den entfernten Bibliotheken, die es abzurufen versuchte. Also musste ich kein Flag hinzufügen (sagen wir, -fPIC) zu der durch den Verschiebungsfehler unterbrochenen Kompilierung. Stattdessen habe ich die entfernte Bibliothek neu kompiliert, sodass die gemeinsam genutzten Objekte verfügbar waren.
Im Grunde war es ein getarnter Datei-nicht-gefunden-Fehler.
In meinem Fall musste ich einen verlegten entfernen --disable-shared Schalter ein configure Aufruf für das erforderliche Programm, da gemeinsam genutzte und statische Bibliotheken beide standardmäßig erstellt wurden.
Mir ist aufgefallen, dass die meisten Programme beide Arten von Bibliotheken gleichzeitig erstellen, also ist meine wahrscheinlich ein Eckfall. Generell kann es sein, dass Sie je nach Voreinstellung lieber Shared Libraries aktivieren müssen.
Um Ihre spezielle Situation mit Kompilierungsschaltern und Standardwerten zu untersuchen, würde ich die Zusammenfassung vorlesen, die mit angezeigt wird ./configure --help | less, normalerweise im Abschnitt Optionale Funktionen. Ich habe oft festgestellt, dass diese Lektüre zuverlässiger ist als Installationsanleitungen, die nicht aktualisiert werden, während sich Abhängigkeitsprogramme weiterentwickeln.
Perfekt, “es war ein getarnter Datei-nicht-gefunden-Fehler.” In meinem Fall wurde die Abhängigkeit noch nicht installiert.
– Litty
9. April 17 um 8:51 Uhr
+1 In meinem Fall wurde eine neuere Kopie von openssl manuell erstellt und ohne gemeinsam genutzte Bibliotheken installiert. Die Bibliothek, die ich zu erstellen versuchte, wurde bereits mit -fPIC kompiliert. Gibt es trotzdem, dass der Compiler diesen Fehler erkennen könnte, um eine weniger obskure Fehlermeldung auszugeben, z. ?
– Rohan Mahy
11. Juli 17 um 3:36 Uhr
Danke. Ich hatte ein make -j und die parallele Ausführung war für dieses Softwarepaket nicht erlaubt.
– MikeBergmann
13. Juni 18 um 8:39 Uhr
In meinem Fall habe ich diese Zeile “find_library (NGHTTP2_LIB NAMES libnghttp2.a libnghttp2.so libnghttp2.dylib)”. und es nahm nur die .a-Datei auf, ich änderte sie später in find_library (NGHTTP2_LIB NAMES libnghttp2.so libnghttp2.a libnghttp2.dylib)” und es fing an zu funktionieren. Meine Sorge ist, was es früher für mich funktioniert hat?
– Naba Chinde
29. April 20 um 6:49 Uhr
@NabaChinde Ich fürchte, ich habe keine Antwort auf Ihre Frage, auch weil mir Kontextinformationen zu Ihren Ergebnissen fehlen. Ich würde auf jeden Fall dazu ermutigen, eine separate Frage zu stellen, in der Sie Ihre Arbeitssituation und das unerwartete Verhalten erläutern.
– XavierStuvw
29. April 2020 um 8:48 Uhr
Habe es mit behoben -no-pie Option in der Linker-Phase:
Es liegt nicht immer an den Kompilierungs-Flags, ich habe den gleichen Fehler auf Gentoo, wenn ich distcc verwende.
Der Grund ist, dass auf dem distcc-Server ein nicht gehärtetes Profil verwendet wird und auf dem Client das Profil gehärtet ist. Überprüfen Sie diese Diskussion: https://forums.gentoo.org/viewtopic-p-7463994.html
Gábor Kiss-Vámosi
Durch einfaches Reinigen des Projekts wurde es für mich gelöst.
Mein Projekt ist eine C++-Anwendung (keine gemeinsam genutzte Bibliothek). Ich habe diesen Fehler zufällig nach vielen erfolgreichen Builds erhalten.
Samuel Liew
Ich hatte das gleiche Problem. Versuchen Sie es mit einer Neukompilierung -fPIC Flagge.
V Li
Ich bekomme die gleiche Lösung wie @caminos Kommentar zu https://stackoverflow.com/a/19365454/10593190 und XavierStuvws Antwort.
Ich habe es zum Laufen gebracht (für die Installation von ffmpeg), indem ich einfach das Ganze von Anfang an mit allen Instanzen von neu installiert habe $ ./configure ersetzt durch $ ./configure --enable-shared (Achten Sie zuerst darauf, alle Ordner und Dateien einschließlich der .so-Dateien vom vorherigen Versuch zu löschen).
Anscheinend funktioniert das, weil https://stackoverflow.com/a/13812368/10593190.
.
7843400cookie-checkKompilierung schlägt fehl mit “Relocation R_X86_64_32 gegen `.rodata.str1.8′ kann nicht verwendet werden, wenn ein gemeinsames Objekt erstellt wird”yes
Hast du versucht
recompile with -fPIC
?– Joachim Isaksson
14. Oktober 13 um 16:44 Uhr
Tut mir leid, aber ich bin mir nicht sicher, wie ich das machen soll. Kann bei Google nichts über “-fPIC” finden.
– Benutzer1667191
14. Oktober 13 um 16:49 Uhr
Versuchen Sie so etwas wie
COMPILE_FLAGS=-c -O3 -w -DLINUX -fPIC -I../SDK/amx/
– Joachim Isaksson
14. Oktober 13 um 17:05 Uhr
Siehe auch: stackoverflow.com/questions/6093547/…
– Ciro Santilli 新疆再教育营六四事件法轮功郝海东
22. Oktober 15 um 20:16 Uhr
Wenn Sie bei Google nach -fPIC suchen, werden Sie sicherlich nichts finden. Entfernen Sie das Minus oder verwenden Sie Anführungszeichen “-fPIC”, sonst lassen Sie alle Ergebnisse weg, die fPIC enthalten.
– d00d
7. Juli 17 um 7:49 Uhr