Kontext: Ich kann eine Shared-Objekt-Bibliothek erstellen, die ohne Probleme auf 32-Bit-Linux mit einer statischen Bibliothek verbunden ist. Wenn ich dasselbe Build auf 64-Bit-Linux versuche, sehe ich diesen Linker-Fehler:
Dieser Fehler ist im Web ziemlich verbreitet. Die Lösung besteht darin, die statisch verknüpfte Bibliothek mit positionsunabhängigem Code (-fPIC) zu kompilieren.
Was ich nicht verstehe ist, warum das für den 32bit Build nicht benötigt wird. Kann mir jemand helfen?
Ok, die Antwort wird hier im Detail beschrieben: Ссылка .
Der Grundgedanke der Erklärung ist, dass die i386-Architektur den Rahmenzeiger für jede Funktion implizit dereferenziert (erklärt im letzten Absatz der verlinkten Seite). Dieser Prozess verursacht zusätzlichen Overhead, so dass dieser Dereferenzierungs-Overhead in den neuen 64-Bit-Architekturen als Optimierung eliminiert wurde.
Die Konsequenz dieser Optimierung aus einer Linkperspektive war, dass, wenn 64-Bit-Code nicht explizit als positionsunabhängiger Code kompiliert wird, Code erzeugt wird, der mit Offsets für seinen Ausführungskontext fest codiert ist.
Dies ist eine unvollständige Erklärung des Inhalts auf der verlinkten Seite, aber es reicht für meine Zwecke.
"Positionsunabhängiger Code" ist immer erforderlich, wenn Ihr Objektmodul in einer gemeinsam genutzten Bibliothek verwendet wird. Es ist in hohem Maße plattformabhängig und verursacht einen gewissen Mehraufwand.
Der Grund, warum Sie es explizit auf amd64, aber nicht auf x386 angeben müssen, ist einfach, dass es der Standard für x86 ist, aber nicht für amd64.
Beachten Sie auch den Unterschied zwischen "-fpic" und "-fPIC":
%Vor%