2009-08-28 35 views

risposta

12

questo funzionerà:.

# Generate position independent code (PIC) 
gcc -fPIC -c -o xxx.o xxx.c 

# Build a shared object and link with static libraries 
ld -shared -static -o xxx.so xxx.o 

# Same thing but with static libc 
ld -shared -static -o xxx.so xxx.o -lc 

Una precisazione: la bandiera -static, se dato a gcc, è passata al linker (ld) e dice di lavorare con la versione statica (.a) di una libreria (specificata con il flag -l), piuttosto che con la versione dinamica (.so).

Un'altra cosa: Sul mio sistema (Debian) l'ultimo esempio dà un libc.a ... ricompilare con -fPIC errore. Abbastanza sicuro che ciò significa che il file libc.a che ho sul mio sistema non è stato compilato con -fPIC. Un apt-cache search libc pic ha dato comunque alcuni risultati.

Consulta anche: Program Library HOWTO, SO: combining .so libs, ld(1), gcc(1)

+0

@Inshalla, penso che il problema è che Possibili possiamo collegare due .so a uno . Finora ho provato e ho fallito. –

+0

Si veda il link "SO: combinazione di .so libs" nella mia risposta. Non sembra esserci un modo semplice per combinare le librerie dinamiche a meno che non siano state collegate con il flag '--relocatable' (vedere la manpage di ld (1)). – Inshallah

+1

@Inshallah: se si desidera collegare un codice non PIC in un oggetto condiviso, è possibile utilizzare i flag gcc "-mimpure-text". Il codice non PIC in oggetti condivisi funziona bene ma ha alcuni compromessi (le code page non possono essere condivise tra processi e richiedono lo spazio di swap, le rilocalizzazioni rallentano il caricamento dell'oggetto condiviso anche se possono essere leggermente più veloci in runtime dato che il codice PIC è ~ 5% più lento). –

0

Se avete in programma sulla portabilità per la vostra libreria condivisa, utilizzare libtool(1). Gestirà la maggior parte dei dettagli delle bandiere del compilatore per te e renderà la tua vita infinitamente più semplice. Se non usi libtool, ma in seguito decidi che vuoi portare il tuo programma su OS X o Windows, finirai per reinventarlo comunque.

+0

@Chris Lutz, creare una libreria indipendente può essere utilizzata per una fonte vicina o più semplice per l'utilizzo da parte del cliente. –

+0

@arsane: libtool (1) consente di creare librerie in modo più indipendente dalla piattaforma. Eseguirà i comandi appropriati per creare una libreria (statica o condivisa) per la piattaforma su cui viene eseguita; buona cosa avere anche se non ne hai bisogno. – Inshallah

+2

@arsane - In generale, gli strumenti GNU non richiedono la licenza del codice sotto licenze GNU per utilizzarli. Puoi legalmente compilare il codice closed-source con GCC e ottenere comunque i vantaggi della portabilità di GCC nel tuo codice sorgente chiuso, quindi penso che tu possa usare libtool per compilare una libreria condivisa senza dover utilizzare la libreria GPL. Non sono un avvocato o un esperto, quindi vedi la licenza pertinente, ma in generale GNU non lo fa. –

2

C'è un po 'di aggiustamenti pulito si può fare con rPath in modo che un eseguibile ELF o .so cercherà per il suo dipendente .so file prima nella stessa directory come se stesso:

  • fare un breve script ECHO rpath costituito da

    echo '-Wl, - rpath = $ ORIGIN'

  • aggiungere che alla riga di comando di compilazione come gcc -o presentare -lwhatever `echo-rpath ` oggetti

(Il meccanismo eco impedisce fare o il guscio dal mangiare il simbolo $ e assicura che venga passato in ld.)

Problemi correlati