Libgcrypt per la compilazione incrociata per iPhone? Errore linker & # 8230; non riesco a trovare & # 8220; fwrite & # 8221; e & # 8220; strerror & # 8221 ;?

StackOverflow https://stackoverflow.com/questions/1620375

Domanda

Ho correttamente compilato in modo incrociato Apache Portable Runtime (APR) per iPhone , utilizzando un set di configura script che invocano gli GNU Autotools " ./ configure " con le opzioni di compilazione incrociata necessarie.

Sto ora tentando di compilare in modo incrociato GNUTLS che dipende da libtasn1 e libgcrypt, che a sua volta dipende dall'errore libgpg. È qui che sto correndo nei guai e potrei usare il tuo aiuto ...

Attualmente sto cercando di compilare in modo incrociato libgpg-error. Gli script di configurazione che ho usato prima funzionano magnificamente; il " ./ configura " il processo si completa in modo pulito. I problemi si verificano quando eseguo " make " ;. Quando eseguo make, tutto sembra compilarsi, ma alla fine ricevo il seguente brutto errore del linker:

/bin/sh ../libtool --tag=CC   --mode=link /Users/michaelsafyan/Downloads/libgpg-error-1.7/compile /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2  -std=c99 -arch armv6 -pipe -no-cpp-precomp --sysroot='/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk' -isystem /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/lib/gcc/arm-apple-darwin9/4.2.1/include/ -isystem /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/include -isystem /Developer/Platforms/iPhoneOS.platform/Developer/usr/include -isystem /opt/iphone-3.0/include -isystem /usr/local/iphone-3.0/include  -arch armv6 --sysroot='/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk' -L/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/lib -L/Developer/Platforms/iPhoneOS.platform/Developer/usr/lib -L/opt/iphone-3.0/lib -L/usr/local/iphone-3.0/lib -o gpg-error gpg_error-strsource-sym.o gpg_error-strerror-sym.o gpg_error-gpg-error.o  ./libgpg-error.la  
/Users/michaelsafyan/Downloads/libgpg-error-1.7/compile /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -std=c99 -arch armv6 -pipe -no-cpp-precomp --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk -isystem /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/lib/gcc/arm-apple-darwin9/4.2.1/include/ -isystem /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/include -isystem /Developer/Platforms/iPhoneOS.platform/Developer/usr/include -isystem /opt/iphone-3.0/include -isystem /usr/local/iphone-3.0/include -arch armv6 --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk -o gpg-error gpg_error-strsource-sym.o gpg_error-strerror-sym.o gpg_error-gpg-error.o  -L/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/lib -L/Developer/Platforms/iPhoneOS.platform/Developer/usr/lib -L/opt/iphone-3.0/lib -L/usr/local/iphone-3.0/lib ./.libs/libgpg-error.a
Undefined symbols:
  "_fwrite$UNIX2003", referenced from:
      _main in gpg_error-gpg-error.o
  "_strerror$UNIX2003", referenced from:
      _gpg_strerror in libgpg-error.a(libgpg_error_la-strerror.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [gpg-error] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Qualche idea su come farlo funzionare? Le versioni del software che sto compilando sono:

      
  • errore libgpg: 1.7
  •   
  • libgcrypt: 1.4.4
  •   
  • libtasn1: 2.2
  •   
  • gnutls: 2.8.4

Per favore aiuto. Grazie.

Aggiornamento

Come da feedback iniziale, ogni SDK ha una copia di "libSystem.dylib" in " $ SDKROOT / usr / lib " ;. Non esiste alcuna copia di libSystem in " $ DEVROOT / usr / lib " ;, dove:

      
  • $ DEVROOT = " /Developer/Platforms/iPhoneOS.platform/Developer"
  •   
  • $ SDKROOT = " $ DEVROOT / SDKs / iPhoneOS $ VER.sdk "

Il " libSystem " le librerie contengono le versioni ordinarie e non decorate di ciascun simbolo, ma non contengono " $ UNIX2003 " varianti dei simboli. Ho il sospetto che GPG-ERROR stia definendo "_POSIX_C_SOURCE", "UNUN" o un'altra macro di test di funzionalità UNIX e che un'intestazione errata che stia aggiungendo "$ UNIX2003"; alle funzioni quando sono presenti queste macro di test di funzionalità sono state incluse. Rimozione di " $ DEVROOT / usr / include " dall'elenco delle directory include non ha alcun effetto per quanto riguarda la rimozione di questo messaggio di errore.

Come ultima risorsa, vedo che " ld " accetta una " -alias_list " opzione che consente di specificare un file con voci come " _fwrite _fwrite $ UNIX2003 " per risolvere forzatamente questi simboli indefiniti nelle loro varianti non decorate. Se possibile, vorrei evitare questa opzione, poiché sembra hacker e potenzialmente pericoloso.

È stato utile?

Soluzione

Solitamente un simbolo $ UNIX2003 solitamente non risolto che stai collegandoti a un SDK più vecchio di quello con cui sono stati creati i file oggetto esistenti .

Uno strano aspetto include il percorso verso di me, e tieni presente che ho solo vagamente familiarità con lo sviluppo del Mac e non lo sviluppo dell'iPhone, è il percorso

/Developer/Platforms/iPhoneOS.platform/Developer/usr/include

che non si trova effettivamente nella cartella SDK. È possibile che tu abbia raccolto i simboli canaglia, se sono così, da lì? Sembra improbabile poiché si verifica più tardi nella riga di comando rispetto all'SDK include percorsi.

Forse invece i simboli sono le versioni previste di _fwrite e _strerror e quindi gpg_error-gpg-error.o e libgpg -error.a va bene ed è davvero un problema di collegamento, anche se di nuovo improbabile come hai

/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/lib

come opzione -L. Suppongo che ci sia un dylib libSystem da qualche parte?

Immagino che la prima cosa da fare sia accertare se la versione UNIX2003 del simbolo è quella che ti aspetti o meno. La mia ipotesi è che lo sia, ma come ho detto potrei sbagliarmi completamente. :)

In secondo luogo, potresti provare a ottenere un output dettagliato da ld per vedere dove sta trovando i simboli. Sono sicuro che esiste una variabile d'ambiente che puoi impostare per far sì che ciò accada, ma non riesco a vedere nessuno elencato nella pagina man online per ld . ( Aggiorna : le due variabili env sono LD_TRACE_ARCHIVES e LD_TRACE_DYLIBS ma forse danno lo stesso -t?).

Modifica

OK, quindi mi sbagliavo completamente sul fatto che i simboli UNIX2003 fossero quelli richiesti. lol.

Quando hai creato l'errore libgpg penso che abbia creato un file

src / .deps / gpg_error-gpg-error.Po

che contiene dipendenze dell'intestazione (almeno sul mio sistema Linux). Questo potrebbe dare un indizio su dove abbia preso l'intestazione sbagliata durante la creazione di gpg_error-gpg-error.o.

A proposito, sembra che lo script di configurazione dell'errore libgpg accetti entrambe le opzioni -isysroot e -arch . Non puoi usare quelli al posto della tua versione dello script configure?

Edit2:

Ok, facciamo un altro tentativo :) Ecco alcune cose da provare, a partire da una cartella di origine pulita:

  • usa -isysroot invece di --sysroot
  • usa -isysroot e --sysroot
  • rende temporaneamente non disponibili le normali intestazioni di sistema, ad esempio rinominando la cartella. Spero che la build cadrà non riuscendo a trovare un'intestazione e ti dirà esattamente dove.

Altri suggerimenti

Prova a preelaborare gpg_error-gpg-error.c con -E, quindi cerca i simboli mancanti. Dovresti trovare da dove ci sono inclinati (qualcosa come asm (" _ " " nice " " @ UNIX2003 "). Quindi, modifica questa intestazione (unistd.h per esempio per aggiungere un #warning " HERE "). Ora ricompila e dovresti trovare lo stack di inclusione.

Il suffisso $ 2003 è generato dal compilatore in alcune circostanze che puoi trovare completamente documentato nella voce manuale per compat

man compat

Ho lottato con questo per qualche tempo prima di risolverlo infine impostando

-mmacosx-versione-min = 10.3

Qualsiasi versione precedente alla 10.4 farà il lavoro. Sospetto che, data la risposta di Troubadour, potrebbe essere meglio cercare biblioteche collegate erroneamente usando l'opzione -t di ld

Spero che questo aiuti.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top