Ich habe kürzlich eine bestimmte gemeinsam genutzte Bibliothek (ELF) erstellt, die auf die x86-64-Architektur abzielt, wie folgt:
g++ -o binary.so -shared --no-undefined ... -lfoo -lbar
Dies schlug mit folgendem Fehler fehl:
Verschiebung R_X86_64_32 gegen `ein lokales Symbol’ kann nicht verwendet werden, wenn ein gemeinsames Objekt erstellt wird; mit -fPIC neu kompilieren
Das bedeutet natürlich, dass ich es als positionsunabhängigen Code neu erstellen muss, damit es für die Verknüpfung mit einer gemeinsam genutzten Bibliothek geeignet ist.
Aber das funktioniert perfekt auf x86 mit genau den gleichen Build-Argumenten. Die Frage ist also, wie sich die Verlagerung auf x86 von x86-64 unterscheidet und warum ich nicht mit kompilieren muss -fPIC auf ersterem?
Ich habe das nie verstanden. Wenn der Compiler Ihnen genau sagen kann, welche Option automatisch verwendet werden soll, warum müssen Sie dann Zauberworte sagen, damit er richtig funktioniert? Grrr..
– Billy ONeal
2. August 2010 um 3:25 Uhr
@Billy ONeal, jetzt glaube ich, dass dies der Fall einer undichten Abstraktion ist. Sie unterscheiden sich darin, wie sie globale Daten laden, was sich darauf auswirkt, ob PIC benötigt wird oder nicht.
– Alex B
2. August 2010 um 3:40 Uhr
Ich verstehe die Notwendigkeit des Unterschieds. Was ich nicht verstehe, ist, warum Sie dem Compiler einen Schalter geben müssen, damit er das tut.
– Billy ONeal
2. August 2010 um 12:12 Uhr
@Billy, der Fehler kommt vom Linker
– Gearoid Murphy
25. September 2012 um 15:19 Uhr
@GearoidMurphy: Okay, 6 davon, ein halbes Dutzend von anderen. Die Kompilierung wurde mit einem einzigen Aufruf von g++ aufgerufen (anstelle von Aufrufen des Compilers und Linkers separat), daher sollte g++ leicht erkennen können, ob eine Compiler-Option eine entsprechende Linker-Option erfordert.
– Billy ONeal
25. September 2012 um 16:32 Uhr