Programar para Dingux

[Ruxy]

A mi tambien me gustaria que explicaseis como dejarlo listo para programar, y ademas, si alguien se anima a explicar, o mejor, dejar unos ejemplos practicos de como dibujar en pantalla, y cosas similares, que como mas se aprende es mirando ejemplo hechos (se que hay algunos, pero creo que no son para programar para dingux, creo que son para el menu de la maquina).

Ah, y si la explicación es en linux mejor , así de paso se puede ir trasteando con linux.

[Kiwiz]

Ruxy, prueba a mirarte ejemplos de GP2X, ya que se programa de forma parecida.

En cuanto a lo del tutorial del toolchain a mi me interesa en win.

Saludos.

[Uncanny]

Bien, lo voy a enfocar en el desarrollo desde una distro de Linux porque el toolchain está construido para Linux, aunque si usáis Windows podéis optar por instalar andLinux, una distro cuyo kernel Linux, coLinux, ha sido portado a Win32 para funcionar junto con Windows, como un servicio o aplicación del mismo (para entenderlo mejor podeis ver el video de esta página), eso si, no puedo garantizar de que de esta forma funcione todo perfectamente puesto que no tiendo a usar mucho Windows.

Intentaré ser lo más directo y breve posible, esto le será más facil de entender a quien tenga nociones de programación en Linux, especialmente si ha desarrollado algo para GP2X, a quienes no puede les cueste más entender algún paso, si es así podría desarrollar un tutorial ya sea por aquí o en un documento tipo PDF que sea más elaborado y detallado que este con algunos conceptos más. Al grano, empecemos:

Mini-Tutorial para empezar a portar/desarrollar aplicaciones y/o juegos para Dingux.

Para empezar lo que debemos hacer es descargar el paquete con el toolchain y las bibliotecas de desarrollo (incluida SDL) para Dingux. En el momento de escribir este documento se encuentra disponible esta versión del toolchain dingux-toolchain-20090728.tar.bz2.

Abrimos una sesión del emulador terminal que prefiramos y procedemos a su descarga, en nuestro /home de usuario mismo:

wget -c http://dingoo-linux.googlecode.com/files/dingux-toolchain-20090728.tar.bz2

Una vez descargado lo descomprimimos en /opt:

sudo tar xvjf dingux-toolchain-20090726.tar.bz2 -C /opt

Si queremos poder modificar el toolchain (p.e: compilando y añadiendo más bibliotecas a posteriori) sin necesidad de anteponer sudo o autentificarse como root, podemos darle permisos a ese directorio que acabamos de descomprimir para que nuestro usuario actual sea el dueño de dicho directorio y pueda realizar modificaciones sobre él:

sudo chown -R $USER /opt/mipsel-linux-uclibc/

Ahora añadimos el directorio de binarios que contienen las herramientas del toolchain (compilador, ensamblador, enlazador, etc, toda la pesca para desarrollar aplicaciones) a la variable de entorno PATH:

export DINGUX_TOOLCHAIN=/opt/mipsel-linux-uclibc 
export DINGUX_TOOLCHAIN_PREFIX=$DINGUX_TOOLCHAIN/usr 
export PATH=$PATH:$DINGUX_TOOLCHAIN/usr/bin

Hemos creado una variable de entorno llamada $DINGUX_TOOLCHAIN que contiene la ruta al directorio /bin del toolchain y luego hemos añadido dicha variable de entorno a la de $PATH, el objetivo de todo esto es tener accesibles, desde linea de comandos y en la sesión actual del emulador de terminal, las herramientas del toolchain sin necesidad de usar toda la ruta. Podemos comprobar que funciona de esta forma:

mipsel-linux-gcc -v

Debemos ver que nos devuelve la salida del mismo, algo así:

Using built-in specs. 
Target: mipsel-linux-uclibc 
Configured with:
[...]
Thread model: posix 
gcc version 4.3.3 (GCC)

El inconveniente de este método que es siempre tendremos que escribir estos “export” cada vez que quisiéramos tener disponibles las herramientas del toolchain directamente sin necesidad de usar las rutas absolutas. Una forma sencilla de solventarlo es hacer que estas variables se inicialicen siempre que iniciemos nuestra sesión de usuario (en este caso del actual) de esta forma:

echo '' >> ~/.profile 
echo 'export DINGUX_TOOLCHAIN="/opt/mipsel-linux-uclibc' >> ~/.profile 
echo 'export DINGUX_TOOLCHAIN_PREFIX=$DINGUX_TOOLCHAIN/usr' >> ~/.profile 
echo 'export PATH=$PATH:$DINGUX_TOOLCHAIN/usr/bin' >> ~/.profile 
source ~/.profile

De esta forma podemos "compilar" nuestros programas en código fuente desde la linea de comandos, imaginando que tenemos el típico "Hola Mundo" en un programa simple en C (ni SDL ni nada, con un simple printf()), llamado hola_mundo.c, compilarlo sería tan sencillo como:

mipsel-linux-gcc -o hola_mundo.dge hola_mundo.c

La extensión ".dge" es totalmente opcional, como si ponemos cualquier otra o ninguna, Dingux está basado en Linux y este no distingue un archivo por su extensión como en Windows, pero puede sernos de utilidad para distinguirlo nosotros como ejecutable para Dingux. Si hacemos un file del archivo hola_mundo.dge veremos que es correcto:

file hola_mundo.dge
hola_mundo.dge: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked (uses shared libs), not stripped

Ya solo queda copiar este archivo en nuestra miniSD (por ejemplo en /local/bin) después de hacerlo la insertamos en nuestra Dingoo y arrancamos Dingux. Una vez que Dingux ha arrancado, conectamos el cable USB a la Dingoo, con lo que se debería iniciar una conexión de USBNet por la interfaz usb0 o similar (un ifconfig -a nos lo mostrará), solo tenemos que conectarnos a la IP de la Dingoo por Telnet:

telnet 10.1.0.2
cd /usr/local/bin/
./hola_mundo.dge

Debería verse un "Hola Mundo" en la salida del programa desde el emulador de terminal, lo que indica que todo funciona correctamente.

Por último, un par de "tips" o consejos a tener en cuanta a la hora de compilar programas, ya sean nuestros o un port de algún otro existente. Lo primero, cuando hacemos uso de alguna biblioteca en nuestros programas (como SDL) es necesario indicarle las rutas, tanto de cabeceras (usando la opción -I/ruta/a/include) como de las bibliotecas (con -L/ruta/a/lib), ya sea el enlazado dinámico o estático, listándolas por su nombre (todas empiezan por lib es decir libNombre y se usa la opción -lNombreBiblioteca sin el "lib" para referirse a ellas, p.e: libNombre.so / libNombre.a -> -lNombre). Es importante para el enlazador el orden en el que dispongan (ya sea en la linea de comandos o en un Makefile) ya que en el momento de resolver simbolos habrá dependencias entre algunas de ellas (por ejemplo, libSDL_image depende libjpeg y libpng, y ante todo depende depende libSDL -> -lSDL -lSDL_image -ljpeg -lpng) y si están incorrectamente dispuestas o falta alguna puede dar un error de enlazado aunque todo se haya compilado y ensamblado correctamente. Un ejemplo de un posible programa en SDL, llamemosle Hola_SDL.c:

mipsel-linux-gcc Hola_SDL.c \
-o Hola_SDL.dge \
-I$DINGUX_TOOLCHAIN_PREFIX/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT \
-L$DINGUX_TOOLCHAIN_PREFIX/lib -lSDL -lpthread

Hay otro consejo a tener en cuenta, en especial cuando queremos portar aplicaciones o juegos cuyo código fuente está organizado con las GNU Autotools (Autoconf, Automake, etc), que son los típicos donde no hay un Makefile directamente, sino que se genera el Makefile una vez ejecutamos un script llamado "configure". Para estos programas con el código fuente organizado con autotools hay que pasarle un parámetro que es determinante cuando realizamos una compilación cruzada, "--host", que le indicará para que arquitectura y sistema operativo se va construir el programa, así como el prefijo para GCC y Binutils debe usar (el de nuestro toolchain, mipsel-linux-*) y ciertas variables de entorno que se deberían anteponer para generar un Makefile lo más correcto posible para compilarlo para Dingux:

CFLAGS="-I$DINGUX_TOOLCHAIN/usr/include" \ 
CXXFLAGS="-I$DINGUX_TOOLCHAIN/usr/include" \ 
LDFLAGS="-L$DINGUX_TOOLCHAIN/usr/lib" \ 
CC="mipsel-linux-gcc" \ 
CXX="mipsel-linux-g++" \
./configure --host=mipsel-linux --prefix=$USER/tu_programa

Ya solo es cuestión de hacer un make y si todo es correcto obtendremos el archivo binario y ejecutable para Dingux, sería solo cuestión de copiarlo a la miniSD donde prefiramos (junto con los archivos necesarios, datos como imagenes, sonidos, etc.). Si queremos, además, podemos realizar un make install, esto haría que todo lo necesario se copiase a la una ruta que hemos puesto al parámetro "--prefix" (en el ejemplo, en tu home de usuario, en un directorio llamado tu_programa), así, con copiar dicho directorio en la miniSD y lanzándolo en Dingux (ya sea por el dmenu o por Telnet) debería funcionar correctamente.

Bueno, creo que como base es suficiente para empezar, no he tocado temas como crear Makefiles o detalles más complejos porque no es el objeto de este mini-tuto, como he dicho podría pensar en hacer un documento más completo que trate temas como estos, pero me llevará algo de tiempo. Si teneis alguna duda o veis algún fallo decidlo por aquí

[balrogsoft]

Muy util la guia, muchas gracias. Ya tengo instalado el toolchain, pero me encuentro con una dependencia, no encuentra, glibc 2.8, estoy intentando compilar el UAE4ALL ya he modificado el Makefile, creo que correctamente, y me da este error con el primer fichero:

/opt/mipsel-linux-uclibc/usr/bin/../libexec/gcc/mipsel-linux-uclibc/4.3.3/cc1plus: /lib32/libc.so.6: version `GLIBC_2.8' not found (required by /opt/mipsel-linux-uclibc/usr/bin/../libexec/gcc/mipsel-linux-uclibc/4.3.3/cc1plus)
make: *** [src/audio.o] Error 1

¿Es posible que falte en el paquete del toolchain de Dingux o hay algún motivo por el que puede dar este error?

[Uncanny]

Originalmente Escrito por balrogsoft

Muy util la guia, muchas gracias. Ya tengo instalado el toolchain, pero me encuentro con una dependencia, no encuentra, glibc 2.8, estoy intentando compilar el UAE4ALL ya he modificado el Makefile, creo que correctamente, y me da este error con el primer fichero:

/opt/mipsel-linux-uclibc/usr/bin/../libexec/gcc/mipsel-linux-uclibc/4.3.3/cc1plus: /lib32/libc.so.6: version `GLIBC_2.8' not found (required by /opt/mipsel-linux-uclibc/usr/bin/../libexec/gcc/mipsel-linux-uclibc/4.3.3/cc1plus)
make: *** [src/audio.o] Error 1

¿Es posible que falte en el paquete del toolchain de Dingux o hay algún motivo por el que puede dar este error?

Como expliqué en un post anterior de este mismo hilo, el toolchain de Dingux, así como el propio sistema del mismo, kernel incluido, está construido con Buildroot y este está basado en la biblioteca uClibc en lugar de GNU Glibc, así que obviamente no vas a encontrar Glibc dentro del toolchain. Ambas son bastante compatibles en lo que respecta a su API, pero hay algunas diferencias y puede darse un problema de incompatibilidad con algún programa, ya sea por como está programado o según que bibliotecas se usen en el mismo.

No se me ocurre ahora mismo una posible causa del error de incompatibilidad o de dependencia de GLibc, revisa el Makefile para ver contra que bibliotecas se debe enlazar y si hay alguna que necesariamente use Glibc, así como el código fuente basándote en el documento de diferencias entre las dos bibliotecas (viendo el error, podrías revisar el archivo fuente del que se genera src/audio.o), puede ser un buen punto de partida. En un mal caso siempre puedes crearte otro toolchain basado en Glibc con Crosstool-NG por ejemplo, eso si, posiblemente tendrías que enlazar estáticamente el UEA4ALL para que funcionara en Dingux, porque dinámicamente sería complicado y es posible que no funcionara incluso aunque hicieras un apaño con un script y forzaras el uso (con variables como LD_LIBRARY_PATH) de las bibliotecas dinámicas de ese toolchain incluyendolas junto al port.

[enkonsierto]

Gracias por el mini-tuto!!! Espero ponerlo en práctica.

[frankitu]

hola! soy nuevo en el foro! me registre para comentaros una experiencia similar a la de balrogsoft que me ha traido de cabeza un par de dias...
siguiento los pasos de Uncanny decidi probar y compilar un "hola mundo" para dingux, pero mi sorpresa vino al recibir el siguiente mensaje:
/opt/mipsel-linux-uclibc/usr/bin/../libexec/gcc/mipsel-linux-uclibc/4.3.3/cc1: /lib32/libc.so.6: version `GLIBC_2.8' not found (required by /opt/mipsel-linux-uclibc/usr/bin/../libexec/gcc/mipsel-linux-uclibc/4.3.3/cc1)

intente compilar mas cosas, pero siempre obtenia errores similares y no encontre nada por internet que me ayudara a aclarar mi problema.
al final decidi probar con otra maquina virtual de linux y funciono
inicialmente use un Ubuntu 8.04 64 bits (la maquina conflictiva), luego probe con Fedora 9 32 bits y Ubuntu 9.04 de 32 bits que funcionaron sin problemas

aunque no he realizado mas pruebas, mi deduccion fue que la toolchain esta preparada para distros de 32 bits
espero que esto ayude a otras personas con el mismo caso
un saludo