it-swarm.com.de

Kompilierung schlägt fehl, wenn "relocation R_X86_64_32 gegen` .rodata.str1.8 'nicht verwendet werden kann, wenn ein Shared Object 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 volle 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 ist los?

63
user1667191

Führen Sie die Anweisungen des Compilers aus, d. H. Rekompilieren Sie ihn mit -fPIC. Um zu erfahren, was dieses Flag macht und warum Sie es in diesem Fall benötigen, lesen Sie Optionen für die Codegenerierung des GCC-Handbuchs.

Kurz gesagt, bezieht sich der Begriff positionsunabhängiger Code (PIC) auf den generierten Maschinencode, bei dem es sich um eine Speicheradressen-Agnose handelt, d. H. Keine Annahmen darüber, wo er in den RAM geladen wurde. Nur der positionsunabhängige Code sollte in Shared Objects (SO) enthalten sein, da er die Möglichkeit haben sollte, seine Position im RAM dynamisch zu ändern.

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

101

In meinem Fall trat dieser Fehler auf, weil ein make-Befehl erwartete, gemeinsam genutzte Bibliotheken (*.so-Dateien) aus einem Remote-Verzeichnis abzurufen, das durch eine Umgebungsvariable LDFLAGS angegeben ist. In einem Fehler standen dort nur statische Bibliotheken zur Verfügung (*.la- oder *.a-Dateien). 

Daher lag mein Problem nicht bei dem Programm, das ich kompilierte, sondern bei den entfernten Bibliotheken, die es abrufen wollte. Daher musste ich der Kompilierung, die durch den Umsetzungsfehler unterbrochen wurde, kein Flag hinzufügen (beispielsweise -fPIC). Ich habe die entfernte Bibliothek vielmehr neu kompiliert, damit die gemeinsam genutzten Objekte verfügbar waren. 

Im Grunde ist es ein versteckter Fehler der Datei, der nicht gefunden wurde.

In meinem Fall musste ich einen falsch platzierten --disable-shared-Schalter im Aufruf von configure für das erforderliche Programm entfernen, da sowohl die gemeinsam genutzten als auch die statischen Bibliotheken standardmäßig erstellt wurden. 


Mir ist aufgefallen, dass die meisten Programme beide Arten von Bibliotheken gleichzeitig erstellen. Daher ist meine wahrscheinlich ein Eckpunkt. Im Allgemeinen kann es vorkommen, dass Sie abhängig von den Standardeinstellungen lieber gemeinsam genutzte Bibliotheken aktivieren müssen. 

Um Ihre spezielle Situation mit Compile-Switches und -Standards zu überprüfen, würde ich die Zusammenfassung mit ./configure --help | less auslesen, normalerweise im Abschnitt Optionale Funktionen. Ich habe oft festgestellt, dass dieses Lesen zuverlässiger ist als Installationsanleitungen, die nicht aktualisiert werden, während sich Abhängigkeitsprogramme entwickeln.

34
XavierStuvw

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

Der Grund ist, dass auf distcc-Server ein nicht gehärtetes Profil verwendet wird und auf dem Client das Profil gehärtet wird. Überprüfen Sie diese Diskussion: https://forums.gentoo.org/viewtopic-p-7463994.html

9
EIIPII

Ein "sauberes" löste es für mich.

Mein Projekt ist eine C++ - Anwendung (nicht gemeinsam genutzte Bibliothek). Ich habe diesen Fehler einmal zufällig erhalten, als ich versuchte, ihn zu kompilieren.

3

Problem mit der Option -no-pie in der Linker-Phase behoben:

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

Ich hatte das gleiche Problem. Versuchen Sie es erneut mit -fPIC-Flag.

0