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

Kompilierung schlagt fehl mit Relocation R X86 64 32 gegen rodatastr18 kann nicht
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

Hier ist mein Makefile:

GPP=g++
GCC=gcc
OUTFILE="TCP_V1.so"

COMPILE_FLAGS=-c -O3 -w -DLINUX -I../SDK/amx/

all:
    $(GCC) $(COMPILE_FLAGS) ../SDK/amx/*.c
    $(GPP) $(COMPILE_FLAGS) ../SDK/*.cpp
    $(GPP) $(COMPILE_FLAGS) *.cpp
    $(GPP) -O2 -fshort-wchar -shared -o $(OUTFILE) *.o

Weiß jemand, was falsch ist?

  • 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

Kompilierung schlagt fehl mit Relocation R X86 64 32 gegen rodatastr18 kann nicht
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

1644072072 29 Kompilierung schlagt fehl mit Relocation R X86 64 32 gegen rodatastr18 kann nicht
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:

g++-8 -L"/home/pedro/workspace/project/lib" -no-pie ...

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

1644072072 189 Kompilierung schlagt fehl mit Relocation R X86 64 32 gegen rodatastr18 kann nicht
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.

1644072073 953 Kompilierung schlagt fehl mit Relocation R X86 64 32 gegen rodatastr18 kann nicht
Samuel Liew

Ich hatte das gleiche Problem. Versuchen Sie es mit einer Neukompilierung -fPIC Flagge.

1644072073 224 Kompilierung schlagt fehl mit Relocation R X86 64 32 gegen rodatastr18 kann nicht
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.

.

784340cookie-checkKompilierung schlägt fehl mit “Relocation R_X86_64_32 gegen `.rodata.str1.8′ kann nicht verwendet werden, wenn ein gemeinsames Objekt erstellt wird”

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy