Hello world

[javiero]

Si quieres te puedo pasar mi toochain para Linux. La compilo contra la misma versión de GLIBC que GPH y ya.

Te agradezco el ofrecimiento, pero es que eso no serviria para windows, no ?

Un saludo. ;-)

[flozanot]

Flozanot, eso ha estado de lujo. Un millón de gracias.

Con todo la info que has puesto no he tenido más remedio que probarlo ya a pesar de que creo que el tema me desborda. Me lo he tomado como una buena manera de iniciarme en el tema del tollchaining.

Te comento.
Finalmente me he decidido por glibc2.6 para ahorrarme la recompilación.
Los pasos 1 y 2 perfecto. Sólo he tenido que añadir al gcc el gmp 4.3.1 y el mpfr 2.4.1.
Por el resto todo bien.
El paso tres sin problemas también pero al llegar al paso 4 kaboom!!..

running configure fragment for ports/sysdeps/arm/elf
checking for ARM TLS support... yes
running configure fragment for nptl/sysdeps/pthread
checking for forced unwind support... no
configure: error: forced unwind support is required
make: *** No hay ninguna regla para construir el objetivo `install-headers'.  Alto.
touch: no se puede efectuar `touch' sobre «/home/xau/toolchain/include/gnu/stubs.h»: No existe el fichero o el directorio
touch: no se puede efectuar `touch' sobre «/home/xau/toolchain/include/bits/stdio_lim.h»: No existe el fichero o el directorio

He revisado el tema en el config.log y he encontrado lo siguiente:

configure:27: checking for forced unwind support
configure:51: arm-unknown-linux-gnu-gcc -o conftest -g -O2   conftest.c  >&5
/home/xau/toolchain/lib/gcc/arm-unknown-linux-gnu/4.4.0/../../../../arm-unknown-linux-gnu/bin/ld: crt1.o: No such file: No such file or directory
collect2: ld returned 1 exit status
configure:57: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME "GNU C Library"
| #define PACKAGE_TARNAME "c-library"
| #define PACKAGE_VERSION "(see version.h)"
| #define PACKAGE_STRING "GNU C Library (see version.h)"
| #define PACKAGE_BUGREPORT "glibc"
| #ifdef __cplusplus
| void exit (int);
| #endif
| #define ASM_GLOBAL_DIRECTIVE .globl
| #define HAVE_ASM_SET_DIRECTIVE 1
| #define ASM_TYPE_DIRECTIVE_PREFIX %
| #define DO_VERSIONING 1
| #define HAVE_ASM_PREVIOUS_DIRECTIVE 1
| #define HAVE_Z_COMBRELOC 1
| #define NO_UNDERSCORES 1
| #define HAVE_ASM_WEAK_DIRECTIVE 1
| #define HAVE_ASM_CFI_DIRECTIVES 1
| #define HAVE_BUILTIN_EXPECT 1
| #define HAVE_BUILTIN_REDIRECTION 1
| #define HAVE___THREAD 1
| #define HAVE_TLS_MODEL_ATTRIBUTE 1
| #define SIZEOF_LONG_DOUBLE 0
| #define HAVE_TLS_SUPPORT 1
| /* end confdefs.h.  */
| #include <unwind.h>
| int
| main ()
| {
| 
| struct _Unwind_Exception exc;
| struct _Unwind_Context *context;
| _Unwind_GetCFA (context)
|   ;
|   return 0;
| }
configure:82: result: no
configure:156: error: forced unwind support is required

He leido tantos documentos que ya no se por donde continuar. He visto algo al respecto de necesitar una doble compilación.
¿¿quizás era eso a lo que te referías al usar glibc 2.9??

No se muy bien por donde seguir, ¿alguna sugerencia?

< - >

Por cierto, aunque parece un poco desfasado, he encontrado buena documentación para la construcción de toolchains que puede ser útil para la gente que como yo, esto se le hace grande

Aquí la enlazo.

http://www.aleph1.co.uk/oldsite/arml...OWTO/x183.html

"forced unwind support is required":
¡Que extraño!. Prueba a repetir el paso 2 (build_2.sh) con la opción en configure "--enable-shared".
Como sea eso, me vi a cagar en to lo que se menea. Un momento y actualizo el guión.

< - >

Me estoy quedando a cuadros , cómo que soporte VFP? Creo que el procesador ARM de la Wiz no soporta punto flotante por hardware. Aunque el tener aceleradora 3D también me hace dudar. El SDK de la GP2X que estamos usando lo hace todo por software. Pero como sea verdad esto y funcionen las cosas con VFP en la Wiz va a ser el bombazo del siglo.

Yo tampoco lo creía, pero al compilar contra las OpenGL, me demandaba soporte VFP Así que me armé de paciencia y compila mi toolchain con -mhard-float y -mvfp. E hice un test consistente en sumar, restar, multiplicar y dividir floats compilando para hardware (-mvfp) y la Wiz se los tragaba sin problemas (puse salidas de texto para comprobar que no se quedaban colgados).
De todas formas, las extensiones Jazelle implican VFP ¿no? vamos, leido así por encima. Que alguien me corrija o me diga si tengo razón o no
Con tanta cosa yo ya estoy MUY confuso respecto a lo que tiene o no la Wiz. Desde luego, si se confirma que trae VFP la Pandora lo va a pasar muy mal.

Estoy ahora con el tema, así que si averiguo algo más, lo digo.

[xau]

"forced unwind support is required":
¡Que extraño!. Prueba a repetir el paso 2 (build_2.sh) con la opción en configure "--enable-shared".
Como sea eso, me vi a cagar en to lo que se menea. Un momento y actualizo el guión.

Te confirmo que el "--enable-shared" no soluciona el problema.

Lo he solventado añadiendo al build_4.sh lo siguiente (justo después del cd BUILD/glibc-2.9-headers) para forzar el soporte unwind:

echo "libc_cv_forced_unwind=yes" > config.cache
echo "libc_cv_c_cleanup=yes" >> config.cache
echo "libc_cv_mlong_double_128=yes" >> config.cache
echo "libc_cv_alpha_tls=yes" >> config.cache

Posteriormente hay que añadir al configure la opción "--cache-file=config.cache"

Una vez arreglado esto, tira hasta que vuelve a fallar (en la versión con glibc 2.6 y también con 2.9) debido a un problema con unas expresiones regulares en el fichero /src/glibc-2.9/scripts/gen-sorted.awk.
Hay que substituir \/[^/]+$ con \/[^\/]+$ en las diferentes lineas en las que falla. Parece que es necesario escapar el / dentro del paréntesis o no lo interpreta.

Después de estos apaños, finaliza el build_4 correctamente con el glibc 2.9.
El mismo patch se necesita para glibc 2.6.

Seguimos con el tema a ver si lo cuadramos

el build_5 sin problemas, pero en el build_6 volvemos a engancharnos.
Intenta compilar sobre el directorio cd BUILD/gcc-4.4.0 donde no encuentra make.
Lo corrijo compilando sobre el cd BUILD/gcc-4.4.0-stage1.

Despues de esto finaliza correctamente el paso 6 y ahora mismo se está compilando el 7. A ver que pasa. xD

[flozanot]

Te confirmo que el "--enable-shared" no soluciona el problema.

Lo he solventado añadiendo al build_4.sh lo siguiente (justo después del cd BUILD/glibc-2.9-headers) para forzar el soporte unwind:

echo "libc_cv_forced_unwind=yes" > config.cache
echo "libc_cv_c_cleanup=yes" >> config.cache
echo "libc_cv_mlong_double_128=yes" >> config.cache
echo "libc_cv_alpha_tls=yes" >> config.cache

Posteriormente hay que añadir al configure la opción "--cache-file=config.cache"

Una vez arreglado esto, tira hasta que vuelve a fallar (en la versión con glibc 2.6 y también con 2.9) debido a un problema con unas expresiones regulares en el fichero /src/glibc-2.9/scripts/gen-sorted.awk.
Hay que substituir \/[^/]+$ con \/[^\/]+$ en las diferentes lineas en las que falla. Parece que es necesario escapar el / dentro del paréntesis o no lo interpreta.

Después de estos apaños, finaliza el build_4 correctamente con el glibc 2.9.
El mismo patch se necesita para glibc 2.6.

Seguimos con el tema a ver si lo cuadramos

el build_5 sin problemas, pero en el build_6 volvemos a engancharnos.
Intenta compilar sobre el directorio cd BUILD/gcc-4.4.0 donde no encuentra make.
Lo corrijo compilando sobre el cd BUILD/gcc-4.4.0-stage1.

Despues de esto finaliza correctamente el paso 6 y ahora mismo se está compilando el 7. A ver que pasa. xD

Ejem... pues veras, resulta que tenia mi perfil de usuario Linux "contaminado" con ciertos parámetros que favorecían el buen funcionamiento de los guiones.
Acabo de ingresar como "root" y ahora me esta construyendo la glibc, osea, que es un problema en los guiones que creo haber solucionado ya. No voy a modificar nada no sea que vuelva a meter la pata. Disculpas a todos... esto de ser tan torpe...

[xau]

Acabé la compilación del toolchain con exito. (el de glibc 2.9)

Después de ordenar algunos directorios y de meterle los includes y libs de gp2x, he probado de compilar alguna cosa con la toolchain nueva y mi gozo en un pozo.

/home/xau/new-toolchain/bin/arm-unknown-linux-gnu-gcc main.c -o hellobasico.wiz.gpe -I/home/xau/new-toolchain/arm-unknown-linux-gnu/include -L/home/xau/new-toolchain/arm-unknown-linux-gnu/lib

/home/xau/new-toolchain/lib/gcc/arm-unknown-linux-gnu/4.4.0/../../../../arm-unknown-linux-gnu/bin/ld: crt1.o: No such file: No such file or directory
collect2: ld devolvió el estado de salida 1

el crt1.o este me lleva de cabeza.
Llevo un rato buscando y no encuentro nada. Estoy ya un poco desesperado.

¿algún consejo?

[flozanot]

Bueno, pues la compilacion de glibc fue aparentemente perfecta... ahora estoy compilando el gcc con c, c++, java y fortran. Si va bien, pondré los guiones y la toolchain ya precompilada.

Me he estado mirando la documentación el procesador arm926tj-s y ese "-s"... ¿no tendrá algo que ver con el coprocesador vfp9-s?
La verdad es que no sé que pensar por un lado dicen que Pollux no tiene coprocesador VFP, pero por otro lado al enlazar las librerías te dice que estas han sido compiladas para VFP.
Hice algunas pruebas con la toochain que me compile con -mhard-float y la Wiz no se petaba después de las operaciones float de suma/resta y multiplicación/división.
Por si las moscas, reharé las pruebas, no sea que algún "duende" hiciera el "milagro"

Saludos. ¡Y a ver si termina ya de compilar! ¡Menudo !

[Segata Sanshiro]

La verdad es que no sé que pensar por un lado dicen que Pollux no tiene coprocesador VFP, pero por otro lado al enlazar las librerías te dice que estas han sido compiladas para VFP.
Hice algunas pruebas con la toochain que me compile con -mhard-float y la Wiz no se petaba después de las operaciones float de suma/resta y multiplicación/división.
Por si las moscas, reharé las pruebas, no sea que algún "duende" hiciera el "milagro"

Quizás no petaba por lo que explica este usuario de gp32x (la negrita la he puesto yo) :

For the record, the CPU used in Wiz (ARM926EJ) does not have VFP. If you compile a program that has VFP or the older FPA instructions then they'll get trapped by the kernel, which will either emulate them or kill the program depending on how it's configured. If the kernel emulates it then the result will be much slower than if you had the compiler generate code to emulate it, because it involves syscall overhead.

[hardyx]

Por ahí hay miles de tutoriales y cursos de C, pero no conozco ninguno que trate a fondo el tema de compiladores (enlazado de librerías, toolchains, makefiles, etc.), y es un poco difícil trastear sin saber lo mínimo. ¿Alguna web o libro que trate sobre el tema?

La documentación oficial de GCC tiene mucha información.
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/

Aquí por ejemplo, tienes las opciones del compilador explicadas
http://gcc.gnu.org/onlinedocs/gcc-4....l#Invoking-GCC

Y aquí la documentación de SDL
http://www.libsdl.org/cgi/docwiki.cgi/

Quizás no petaba por lo que explica este usuario de gp32x (la negrita la he puesto yo) :

Eso ya me suena más lógico, ya que los ARM de esta familia no soportan VFP. La NDS tiene un ARM que tampoco tiene VFP y sin embargo tiene hardware 3D.

[flozanot]

Bueno, pues he hecho unas pruebas y... la Wiz NO tiene soporte VFP, se las traga porque una isr atrapa la excepción de instrucción no válida.
En cuanto a rendimiento, es más alto con emulación software que con instrucciones hardware. (Pero una bestialidad)
Bueno, miremoslo por el lado positivo, ya no urge tanto una toolchain decente

Ya sólo queda recompilar si o si la OGL que es la que demandaba VFPhard.
He probado nanoGL y GLES y petan por soleares aunque compilar compilan bien.

Saludos.