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

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?

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.

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.

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

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.

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

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.