2012-06-16 15 views
5

Ho creato un gruppo di file .o (tramite gcc -c $file.c $someotherops -o $file.o). Ora voglio collegarli in una libreria statica.come collegare una libreria statica per iOS

Non sono esattamente sicuro se dovrei usare ld o gcc per questo. Nel manuale ld, si dice che non dovrei usarlo direttamente. Tuttavia, non riesco a capire i parametri gcc per creare una libreria statica.

Ho provato ld *.o -static -o libfoo.a ma si lamenta di un sacco di simboli mancanti (penso tutto da libc). Non capisco perché si lamenta perché dovrebbe essere una libreria statica. Ho pensato che avrebbe controllato i simboli una volta che collegassi quella libreria statica ad un'altra cosa.

Un'altra cosa: io uso /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ld qui (il mio obiettivo è iOS). Si lamenta con l'avviso ld: warning: using ld_classic. Cosa riguarda?

Poi ho pensato, forse ha bisogno di avere le librerie dinamiche specificate. Quindi ho aggiunto -lc al collegamento con libc. Ma si lamenta con can't locate file for: -lc. Ho aggiunto -L/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/lib e c'è un libc.dylib.

Qualche idea?


sull'errore -lc: ha ottenuto via dopo ho specificato -arch armv6. Quindi si è lamentato di un errore libcache.dylib (che deve essere collegato da libc.dylib suppongo perché non lo ha specificato). Aggiungere -L.../usr/lib/system aiutato.

Ora, per ogni singolo file .o, ricevo l'avviso ld: warning: CPU_SUBTYPE_ARM_ALL subtype is deprecated. Cosa riguarda?

E ho ancora un sacco di simboli mancanti, esp:

Undefined symbols for architecture armv6: 
    "start", referenced from: 
    -u command line option 
    (maybe you meant: _PyThread_start_new_thread) 
    "___udivsi3", referenced from: 
     _get_len_of_range in bltinmodule.o 
     _quorem in dtoa.o 
     _array_resize in arraymodule.o 
     _newarrayobject in arraymodule.o 
     _array_fromfile in arraymodule.o 
     _get_len_of_range in rangeobject.o 
     _inplace_divrem1 in longobject.o 
     ... 
    "___unorddf2", referenced from: 
     _builtin_round in bltinmodule.o 
    ... 

ho controllato alcuni di quei simboli, per esempio ___udivsi3 in get_len_of_range. Questa funzione utilizza solo l'aritmetica C, nessuna chiamata esterna. Quindi questo sembra essere tradotto per utilizzare alcune funzioni esterne come ___udivsi3. Ma in che biblioteche è questo?


-lgcc_s.1 fissato maggior parte del ___udivsi3 e relativi simboli mancanti. Il simbolo start è ancora mancante. Cosa significa "-u command line option"?


Da here, ho avuto la sensazione che forse ld non è lo strumento giusto, dopo tutto. Qui viene utilizzata una semplice chiamata a ar. E questo sembra avere più senso. Controllerò se funziona e trasformo questo in una risposta.


Durante la riproduzione di più in giro, ar gettare alcuni avvisi di me quando la costruzione di una libreria statica grasso. Mi ha dato invece il suggerimento di usare libtool. Questo è quello che sto facendo ora, cioè libtool -static -o libfoo.a *.o. Inoltre ho cambiato il compilatore in /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang ma non sono sicuro che questo sia importante.

Ora, alla compilazione di una certa applicazione di prova che collega a questa libreria statica, ottengo questi avvertimenti:

ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in __PyBuiltin_Init from /Users/az/Programmierung/python-embedded/libpython.a(bltinmodule.o). To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie 
ld: warning: 32-bit absolute address out of range (0x1001B70C4 max is 4GB): from _usedpools + 0x00000004 (0x001B70CC) to 0x1001B70C4 
ld: warning: 32-bit absolute address out of range (0x1001B70C4 max is 4GB): from _usedpools + 0x00000000 (0x001B70CC) to 0x1001B70C4 

cosa si tratta? Non uso -mdynamic-no-pic. Inoltre, non vedo davvero in _PyBuiltin_Init come utilizzo l'indirizzamento assoluto lì.

Inoltre, quali sono questi indirizzi assoluti fuori portata? Modifica: Queste erano alcune allocazioni davvero enormi. Ho appena rimosso questo codice per ora (questo era WITH_PYMALLOC, se qualcuno è interessato a questi interni specifici di Python).

Quando inizio sul mio iPhone, ottengo l'interruzione:

dyld: vm_protect(0x00001000, 0x00173000, false, 0x07) failed, result=2 for segment __TEXT in /var/mobile/Applications/C15D9525-E7DC-4463-B05B-D39C9CA24319/...

Quando uso -no_pie per il collegamento, lo fa neanche collegamento. Viene a mancare con:

Illegal text-relocation to ___stderrp in /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk/usr/lib/libSystem.dylib from _read_object in /Users/az/Programmierung/python-embedded/libpython.a(marshal.o) for architecture armv7


Ho risolto l'errore PIE disabili, indirizzamento assoluto. Ho avuto un -static nella mia riga di comando Clang. Una volta rimosso, l'avvertimento è sparito, così come l'errore dyld/vm_protect. Era la prima volta che eseguiva del codice.

Fino a quando non ho colpito another strange error about integer comparison. In questo modo sembra più un bug nella loro build Clang.

+0

una domanda; perché non si crea un progetto XCoe Static Library e si crea una libreria statica con quel progetto? – CarlJ

+0

@meccan: Voglio avere il mio script di compilazione in questo caso per vari motivi (principalmente perché per questo particolare progetto, questo è molto più semplice ora). Ad ogni modo, anche se lo farei con Xcode, questa domanda rimane valida/aperta perché voglio capire come farlo manualmente. – Albert

+0

ok, e sai che puoi costruire un progetto Xcode dalla shell? – CarlJ

risposta

12

Tutto funziona ora. In sostanza, la risposta è:

  • limita a compilare ogni *.c file come al solito a *.o file. L'unica vera differenza è il diverso GCC/Clang, lo -arch armv7, i diversi file SDK/include.

  • Utilizzare libtool -static -o libfoo.a *.o per creare la libreria statica.

Questo è tutto. Gli altri problemi nella mia domanda erano solo tentativi sbagliati.

1

Se qualcuno arriva qui con la ricerca per l'errore di runtime dyld: vm_protect(...) ma si sta utilizzando XCode, la bandiera -static menzionato nel PO è probabile il problema.

Sbarazzarlo selezionando "Abilita collegamento con librerie condivise" su "Sì" (impostazione predefinita) nelle impostazioni della lingua del compilatore LLVM. (Questo rimuove GCC_LINK_WITH_DYNAMIC_LIBRARIES = NO dal file di progetto).