linux g ++ collegamento di codice libreria condivisa a 64 bit a librerie statiche

Question

Contesto: Posso creare una libreria di oggetti condivisa che è collegata a una libreria statica senza problemi su linux 32 bit. Quando si tenta la stessa corporatura su 64 bit linux, vedo questo errore di linker:

• delocalizzazione R_X86_64_32S contro `un simbolo locale' non può essere utilizzato quando si effettua un oggetto condiviso; ricompilare con -fPIC

Questo errore è abbastanza comune sul web. La soluzione è compilare la libreria collegata staticamente con codice indipendente dalla posizione (-fPIC).

Quello che non capisco è il motivo per cui non è necessario per la compilazione a 32 bit. Qualcuno può dare una mano?

Answer 1

Ok la risposta è descritto in dettaglio qui: http://www.technovelty.org/code/c/amd64-pic.html.

L'essenza di base della spiegazione è che l'architettura i386 denota implicitamente il puntatore del frame per ciascuna funzione (spiegato nell'ultimo paragrafo della pagina collegata). Questo processo comporta un sovraccarico extra, quindi nelle nuove architetture a 64 bit, questo overhead di dereferenziazione è stato eliminato come ottimizzazione.

La conseguenza di questa ottimizzazione da una prospettiva di collegamento era che a meno che il codice a 64 bit non venga compilato esplicitamente come codice indipendente dalla posizione, produrrà un codice che è hardcoded con offset per il suo contesto di esecuzione.

Questa è una spiegazione imperfetta del contenuto nella pagina collegata ma è sufficiente per i miei scopi.

Answer 2

"Codice di posizione indipendente" è sempre necessario se il modulo dell'oggetto verrà utilizzato in una libreria condivisa. È altamente dipendente dalla piattaforma e comporta un sovraccarico.

Il motivo per cui è necessario specificarlo esplicitamente su amd64, ma non su x386, è semplicemente che è il default per x86, ma non per amd64.

nota, anche, la differenza tra "-fPIC" e "-fPIC":

-fpic 
    Generate position-independent code (PIC) suitable for use in a 
    shared library, if supported for the target machine. Such code 
    accesses all constant addresses through a global offset table 
    (GOT). The dynamic loader resolves the GOT entries when the pro- 
    gram starts (the dynamic loader is not part of GCC; it is part 
    of the operating system). If the GOT size for the linked execu- 
    table exceeds a machine-specific maximum size, you get an error 
    message from the linker indicating that -fpic does not work; in 
    that case, recompile with -fPIC instead. (These maximums are 8k 
    on the SPARC and 32k on the m68k and RS/6000. The 386 has no 
    such limit.) 

    Position-independent code requires special support, and there 
    fore works only on certain machines. For the 386, GCC supports 
    PIC for System V but not for the Sun 386i. Code generated for 
    the IBM RS/6000 is always position-independent. 

    When this flag is set, the macros __pic__ and __PIC__ are defined to 1. 

-fPIC 
    If supported for the target machine, emit position-independent 
    code, suitable for dynamic linking and avoiding any limit on the 
    size of the global offset table. This option makes a difference 
    on the m68k, PowerPC and SPARC. 

    Position-independent code requires special support, and therefore 
    works only on certain machines. 

    When this flag is set, the macros __pic__ and __PIC__ are defined to 2.