Die Kompilierung schlägt fehl mit "Verschiebung R_X86_64_32 gegen" .rodata.str1.8 "kann nicht verwendet werden, wenn ein freigegebenes Objekt erstellt wird"

Ich versuche, diesen Quellcode aus dem Makefile in einem VPS zu kompilieren, aber es funktioniert nicht. Das 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 los ist?

Tun Sie, was der Compiler Ihnen sagt, dh kompilieren Sie mit -fPIC. Informationen dazu, was dieses Flag bewirkt und warum Sie es in diesem Fall benötigen, finden Sie unter Codegenerierungsoptionen im GCC-Handbuch.

Kurz gesagt bezieht sich der Begriff positionsunabhängiger Code (PIC) auf den erzeugten Maschinencode, der speicheradressenunabhängig ist, dh keine Annahmen darüber macht, wo er in den RAM geladen wurde. In gemeinsam genutzten Objekten (SO) sollte nur positionsunabhängiger Code enthalten sein, da diese in der Lage sein sollten, ihren Speicherort im RAM dynamisch zu ändern.

Schließlich können Sie auch auf Wikipedia darüber lesen .

In meinem Fall trat dieser Fehler auf, weil ein makeBefehl erwartete, gemeinsam genutzte Bibliotheken ( *.soDateien) aus einem Remote-Verzeichnis abzurufen, das durch eine LDFLAGSUmgebungsvariable angegeben wird. Aus Versehen waren dort nur statische Bibliotheken ( *.laoder *.aDateien) verfügbar .

Daher lag mein Problem nicht bei dem Programm, das ich kompilierte, sondern bei den Remote-Bibliotheken, die es abzurufen versuchte. Daher musste ich -fPICder Kompilierung, die durch den Verschiebungsfehler unterbrochen wurde , kein Flag (z. B. ) hinzufügen . Vielmehr habe ich die Remote-Bibliothek neu kompiliert, sodass die freigegebenen Objekte verfügbar waren.

Grundsätzlich handelt es sich um einen nicht gefundenen Fehler in der Verkleidung.

In meinem Fall musste ich einen falsch platzierten --disable-sharedSchalter im configureAufruf für das erforderliche Programm entfernen , da sowohl gemeinsam genutzte als auch statische Bibliotheken standardmäßig erstellt wurden.

Mir ist aufgefallen, dass die meisten Programme beide Arten von Bibliotheken gleichzeitig erstellen, daher ist meine wahrscheinlich ein Eckfall. Im Allgemeinen kann es vorkommen, dass Sie gemeinsam mit den Standardeinstellungen gemeinsam genutzte Bibliotheken aktivieren müssen.

Um Ihre spezielle Situation mit Kompilierungsschaltern und Standardeinstellungen zu untersuchen, würde ich die Zusammenfassung vorlesen, die ./configure --help | lessnormalerweise im Abschnitt Optionale Funktionen angezeigt wird. Ich habe oft festgestellt, dass dieses Lesen zuverlässiger ist als Installationshandbücher, die nicht aktualisiert werden, während sich Abhängigkeitsprogramme weiterentwickeln.

Es geht nicht immer um die Kompilierungsflags, ich habe den gleichen Fehler bei gentoo bei der Verwendung von distcc.

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

Es wurde mit der -no-pieOption in der Linker-Phase behoben:

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

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 nach vielen erfolgreichen Builds zufällig erhalten.

Ich hatte das gleiche Problem. Versuchen Sie, mit -fPICflag neu zu kompilieren .

Ich erhalte die gleiche Lösung wie @ caminos Kommentar zu https://stackoverflow.com/a/19365454/10593190 und die Antwort von XavierStuvw .

Ich habe es zum Laufen gebracht (für die Installation von ffmpeg), indem ich das Ganze einfach von Anfang an neu installiert habe, wobei alle Instanzen von $ ./configureersetzt wurden $ ./configure --enable-shared(lösche zuerst alle Ordner und Dateien einschließlich der .so-Dateien aus dem vorherigen Versuch).

Anscheinend funktioniert dies, weil https://stackoverflow.com/a/13812368/10593190 .