¿Compilación cruzada de libgcrypt para iPhone? Error del enlazador & # 8230; parece que no puede encontrar & # 8220; fwrite & # 8221; y & # 8220; strerror & # 8221 ;?

Question

He tenido éxito compilación cruzada de Apache Portable Runtime (APR) para el iPhone , usando un conjunto de configure scripts que invocan las herramientas automáticas de GNU " ./ configure " con las opciones de compilación cruzada necesarias.

Ahora estoy intentando compilar GNUTLS de forma cruzada, que depende de libtasn1 y libgcrypt, que a su vez, depende de libgpg-error. Aquí es donde estoy teniendo problemas y podría usar su ayuda ...

Actualmente estoy intentando compilar de forma cruzada libgpg-error. Los scripts de configuración que he usado antes están funcionando a la perfección; el " ./ configure " El proceso se completa limpiamente. Los problemas ocurren cuando ejecuto " make " ;. Cuando ejecuto make, todo parece compilar, pero al final aparece el siguiente error del desagradable vinculador:

/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

¿Alguna idea sobre cómo hacer que esto funcione? Las versiones del software que estoy compilando son:

  
• error-libgpg: 1.7
  
• libgcrypt: 1.4.4
  
• libtasn1: 2.2
  
• gnutls: 2.8.4

Por favor ayuda. Gracias.

Actualizar

Según los comentarios iniciales, cada SDK tiene una copia de " libSystem.dylib " en " $ SDKROOT / usr / lib " ;. No hay una copia de libSystem en " $ DEVROOT / usr / lib " ;, donde:

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

El " libSystem " las bibliotecas contienen las versiones ordinarias, sin decorar, de cada símbolo, pero no contienen la " $ UNIX2003 " Variantes de los símbolos. Sospecho que GPG-ERROR está definiendo " _POSIX_C_SOURCE " ;, " _UNIX " ;, u otra macro de prueba de características de UNIX, y que un encabezado malicioso está agregando " $ UNIX2003 " Se incluyen las funciones cuando estas macros de prueba de características están presentes. Eliminando " $ DEVROOT / usr / include " de la lista de directorios de inclusión no tiene ningún efecto con respecto a la eliminación de este mensaje de error.

Como último recurso, veo que " ld " acepta un " -alias_list " opción que le permite a uno especificar un archivo con entradas como " _fwrite _fwrite $ UNIX2003 " para resolver por la fuerza estos símbolos indefinidos a sus variantes sin decorar. Si es posible, me gustaría evitar esta opción, ya que parece pirata y potencialmente peligrosa.

Answer 1

Por lo general, un símbolo $ UNIX2003 sin resolver significa que está enlazando con un SDK anterior al que se creó con los archivos de objetos existentes .

Un aspecto extraño incluye una ruta para mí, y tenga en cuenta que solo estoy vagamente familiarizado con el desarrollo de Mac y no con el desarrollo del iPhone, es la ruta

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

que no está realmente en la carpeta SDK. ¿Es posible que hayas recogido los símbolos pícaros, si son eso, desde allí? Parece poco probable, ya que ocurre más adelante en la línea de comandos que el SDK incluye rutas.

Quizás, en cambio, los símbolos son las versiones esperadas de _fwrite y _strerror y por lo tanto gpg_error-gpg-error.o y libgpg -error.a están bien y es realmente un problema de vinculación, aunque de nuevo es poco probable, como lo has hecho

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

como una opción -L. Supongo que hay un dylib libSystem en alguna parte?

Supongo que lo primero que debe hacer es determinar si la versión de UNIX2003 del símbolo es lo que espera o no. Supongo que sí, pero como digo, podría estar completamente equivocado. :)

En segundo lugar, puede intentar obtener una salida detallada de ld para ver dónde se encuentran los símbolos. Estoy seguro de que hay una variable de entorno que puedes configurar para que esto suceda, pero no puedo ver ninguna en la página de manual en línea para ld . ( Actualización : las dos variables env son LD_TRACE_ARCHIVES y LD_TRACE_DYLIBS pero quizás dan lo mismo que -t?).

Editar:

Bien, me equivoqué por completo de que los símbolos UNIX2003 eran los necesarios. lol.

Cuando creaste el error libgpg, creo que habrá creado un archivo

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

que contiene dependencias de encabezado (al menos lo hizo en mi sistema Linux). Esto podría dar una pista de dónde recogió el encabezado incorrecto al compilar gpg_error-gpg-error.o.

Por cierto, parece que el script de configuración libgpg-error configure tanto las opciones -isysroot como -arch . ¿No puede usarlos en lugar de su propia versión del script de configuración?

Editar2:

Está bien, vamos a tener otra oportunidad :) Aquí hay algunas cosas para probar, comenzando desde una carpeta de origen limpia:

• use -isysroot en lugar de --sysroot
• use -isysroot así como --sysroot
• hace que sus encabezados normales del sistema no estén disponibles temporalmente, por ejemplo, cambiando el nombre de la carpeta. Es de esperar que la compilación se caiga al no encontrar un encabezado y te dirá exactamente dónde.

Answer 2

Intente preprocesar gpg_error-gpg-error.c con -E luego busque los símbolos que faltan. Debes encontrar desde donde se incluyen (algo como asm (" _ " " " " " @ UNIX2003 "). Luego, modifique este encabezado (por ejemplo, unistd.h para agregar un #warning " AQUÍ "). Ahora, recompile, y debería encontrar la pila de inclusión.

Answer 3

El compilador genera el sufijo $ 2003 en algunas circunstancias que puede encontrar completamente documentado en la entrada manual para compat

man compat

Luché con esto durante algún tiempo antes de finalmente solucionarlo configurando

-mmacosx-version-min=10.3

Cualquier versión anterior a 10.4 hará el trabajo. Sospecho que dada la respuesta de Troubadour podría ser mejor buscar bibliotecas enlazadas erróneamente usando la opción -t de ld

Espero que esto ayude.