Compilando SDL4gp32 y EABI

**anibarro** · 31/05/2007, 11:06

Iniciado por D_Skywalk

¿alguien conoce alguna opcion de gcc que te cuente todo lo que hace y enlaza? un "verbose" brutal, vamos xD

No se si te valdra con la opcion -M, por ejemplo "gcc -M main.c", que te muestra las dependencias...

**kidchaos2k5** · 31/05/2007, 11:59

Iniciado por D_Skywalk

Lo que he intentado es, tal y como hizo Chui en la vieja libc.a, introducir toda la libreria x_gp32 en libgloss-linux.a y que además hay dos!!

Código:

/opt/gp32/current/lib/libSDL.a(SDL_systimer.o): In function `SDL_Delay':
SDL_systimer.c:(.text+0xd8): undefined reference to `x_gp32_NOP'
SDL_systimer.c:(.text+0xf4): undefined reference to `x_gp32_timer_counter'

Código:

sdltest.o: In function `main':
sdltest.c:(.text+0x4b8): undefined reference to `x_gp32_SetCPUSpeed'
/opt/gp32/current/lib/libSDL.a(SDL_systimer.o): In function `SDL_GetTicks':
SDL_systimer.c:(.text+0x10): undefined reference to `x_gp32_timer_counter'
/opt/gp32/current/lib/libSDL.a(SDL_systimer.o): In function `SDL_SYS_TimerQuit':
SDL_systimer.c:(.text+0x2c): undefined reference to `x_gp32_DisableIRQ'
SDL_systimer.c:(.text+0x38): undefined reference to `x_gp32_InstallSWIIRQ'
SDL_systimer.c:(.text+0x3c): undefined reference to `x_gp32_EnableIRQ'
SDL_systimer.c:(.text+0x4c): undefined reference to `x_gp32_timer_ISR'

Estos errores me son familiares... Un par de recomendaciones, a ver si te valen:

- Algunas de las funciones x_gp32 no están en el syscall.c sino en un fichero ensamblador x_gp32_misc.s, por tanto las tienes que pasar por el ensamblador arm-xxx-as, y añadirlas a la libreria has compilado este fichero ademas de los fuentes .c? en el makefile de chui estan estas lineas:

Código:

src/x_gp32_misc.o: src/x_gp32_misc.s
	$(CC) $(CFLAGS) $(OPTFLAGS) -o src/x_gp32_misc.o -c src/x_gp32_misc.s

OBJS = $(SRCS:.c=.o) src/x_gp32_misc.o

- El orden de las librerias tambien era importante a la hora de enlazar, me parece que yo tambien pasé por eso en su momento y me dediqué a mirar las fuentes del DKARM, pero lo solucioné en base al código de chui ... En el port del beat2x yo lo hacia así: Te pongo trozos del makefile a ver si te vale:
...
(En la compilacón usaba estos flags, igual alguno está de más pero se pasaban a las SDL y a mi programa)

Código:

CFLAGS  = $(INCLUDES) -DOGG_MUSIC -DENABLE_GP32 -DGP32 -DTARGET_GP32

...
(Esto es para enlazar,no hagas caso de la libreria de mirko, por cierto )
LIBS      = -Llib -lx_gp32 -lmirkoSDK -lm -lc
SDLLIBS   =   -lSDL_image -lpng -lz -ljpeg -lSDLx_mixer -lGpTremor -lSDL

...
$(PRG).elf: $(OBJS)
	$(CC) -c -o obj/crt0.o $(CRT0)
	$(LD) -nostartfiles -Wall -T $(LNKSCRIPT) obj/crt0.o -o obj/$(PRG).elf $(OBJS) $(LIBS) $(SDLLIBS)
...

Iniciado por D_Skywalk

Vamos que no esta preguntando por las funciones de la SMC que se curró Chui :-/

Asi que a no ser que se os ocurra algo por donde intentar arreglar el problema del fopen, doy por terminado mi intento, no me queda mucho tiempo más

En lo único que he avanzado es que ahora SDL_mixer y SDL_image no se pelean

Un Saludo, siento las malas noticias y estaré leyendo por si se os ocurre algo :_

Espero ser de ayuda, yo tampoco puedo sacar tiempo... pero a ver si suenan las campanas...

Suerte!

@B^)>

**D_Skywalk** · 31/05/2007, 14:23

Compañero, no tengo ningún problema de librerias<->dependencias xD
Si relees con calma el mensaje explico que lo que he hecho es forzar un error de dependencias para ver si busca las funciones de la SMC en la nueva librería libgloss-linux.a, por ejemplo tendría que intentar buscar la función sm_FATUpdate(), etc...

Y como se ve forzando el error, no busca nada de eso y ahí está el problema que las funciones de fopen y demás están usando dependencias estandar y no las especiales de gp32 :?
No se si ahora se ha quedado más claro

Se anibarro!

Ok, compañero probaré aunque me suena que eso es para hacer un Mapa de dependencias, yo lo que quiero saber es todas las librerías con las que va enlazando en cada momento. A ver si saco de donde demonios está cogiendo las funciones de ficheros :?

Un Saludo y esta tarde probaré otro ratito, de todas formas ¿os interesa o no tener la r11?

**Aiken** · 31/05/2007, 14:26

Iniciado por D_Skywalk

Un Saludo y esta tarde probaré otro ratito, de todas formas os interesa o no tener la r11?

la r11? esa no es la que uso chui? interesaria la ultima que exista elf en todo caso si no se puede la r20. no se si la ultima es la r19 o la r18.

Aiken

**D_Skywalk** · 31/05/2007, 14:29

Iniciado por Aiken

la r11? esa no es la que uso chui? interesaria la ultima que exista elf en todo caso si no se puede la r20. no se si la ultima es la r19 o la r18.

Aiken

No, chui usó alrededor de la r6... aunque me suena que usaba un toolchain de dreamcast, pero no me hagas mucho caso, la cuestión es que usaba un gcc 3.4.1 con msoft. La r11 es un gcc 3.4.3 sin msoft (flotante por hardware).

Un saludo!

[UPDATE]

Código:

$ gcc -v -Wall hello.c
Reading specs from /usr/lib/gcc-lib/i686/3.3.1/specs
Configured with: ../configure --prefix=/usr
Thread model: posix
gcc version 3.3.1
 /usr/lib/gcc-lib/i686/3.3.1/cc1 -quiet -v -D__GNUC__=3 
 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=1 
 hello.c -quiet -dumpbase hello.c -auxbase hello -Wall
 -version -o /tmp/cceCee26.s
GNU C version 3.3.1 (i686-pc-linux-gnu)
 compiled by GNU C version 3.3.1 (i686-pc-linux-gnu)
GGC heuristics: --param ggc-min-expand=51 
 --param ggc-min-heapsize=40036
ignoring nonexistent directory "/usr/i686/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/include
 /usr/lib/gcc-lib/i686/3.3.1/include
 /usr/include
End of search list.
 as -V -Qy -o /tmp/ccQynbTm.o /tmp/cceCee26.s
GNU assembler version 2.12.90.0.1 (i386-linux)
using BFD version 2.12.90.0.1 20020307 Debian/GNU
Linux
/usr/lib/gcc-lib/i686/3.3.1/collect2
 --eh-frame-hdr -m elf_i386 -dynamic-linker
 /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
 /usr/lib/gcc-lib/i686/3.3.1/crtbegin.o
 -L/usr/lib/gcc-lib/i686/3.3.1
 -L/usr/lib/gcc-lib/i686/3.3.1/../../.. /tmp/ccQynbTm.o
 -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
 /usr/lib/gcc-lib/i686/3.3.1/crtend.o
 /usr/lib/crtn.o

No era tan dificil... sería la noche xD

Un Saludo

**Aiken** · 31/05/2007, 14:31

Iniciado por D_Skywalk

No, chui usó alrededor de la r6... aunque me suena que usaba un toolchain de dreamcast, pero no me hagas mucho caso, la cuestión es que usaba un gcc 3.4.1 con msoft. La r11 es un gcc 3.4.3 sin msoft (flotante por hardware).
Un saludo!

Juraria que el la ultima version que hizo, la que era independientemente del sdk oficial, uso la r11 o eso decian los tutoriales.

En cualquier caso la elf mas moderna cual seria? se podria hacer con la elf mas moderna? Y ya puestos, que version de gcc usa la elf mas moderna?

Aiken

**D_Skywalk** · 31/05/2007, 14:48

Iniciado por Aiken

Juraria que el la ultima version que hizo, la que era independientemente del sdk oficial, uso la r11 o eso decian los tutoriales.

En cualquier caso la elf mas moderna cual seria? se podria hacer con la elf mas moderna? Y ya puestos, que version de gcc usa la elf mas moderna?

Aiken

Bueno hacemos un nuevo repaso:

Código:

- r6-r8 (Chui) elf 3.4.1 (libc.a con syscalls.o) (Float por software)
...
- r11          elf 3.4.3 (libc.a con syscalls.o) (Float por hardware)
- r12          elf 3.4.4 (libc.a SIN syscalls.o) (Float por hardware)
...
- r18          elf 4.1.0 (syscalls dividido en m&#250;ltiples librerias)
- r19         eabi 4.1.1 ( " )
- r20         eabi 4.1.1 ( " )

Espero que ahora haya quedado claro

Si se abre con un editor las librerías de Chui, se ven las cabeceras del gcc 3.4.1, asi que como ves es imposible que Chui compilara su sdl4gp32 en la r11

En teoría el problema al que nos enfrentamos no tiene tanto que ver con que sean unos eabi y otros elf, sino que hay que buscar la forma de saber en las versiones posteriores a la r11 (da igual que sea la 12, la 18 o la 20) como suministrarle nuestras funciones especiales de trabajo con ficheros

Un Saludo

Pd: Eso sin contar que hay que revisar las funciones "timer" de x_gp32 que parecen contener algún error que al usar SDL_Delay las hace entrar en un bucle infinito ¿alguien se anima a revisarlas?

**anibarro** · 31/05/2007, 15:40

Si fuese solo cuestion de animarse... xD A mi me gustaria poder ayudar en algo, pero no me entero de la mitad :S

**D_Skywalk** · 01/06/2007, 12:14

Bueno anoche me pegué otro tute con la r20... pero sin suerte

Estuve peleando con la libsysbase.a, que resulta que siempre es llamada por libc.a y contiene más o menos las mismas funciones que se incluyen en el syscalls.o (que es lo que necesitamos que use el compilador).

Pues no he conseguido que el compilador acepte nuestras funciones para abrir ficheros, se ve que las que se incluyen en libc.a tienen más prioridad que las incluidas en libsysbase.a, por cual nuestras funciones de gp32 son ignoradas...

Las funciones además dentro de libc.a están renombradas ahora la función para abrir ficheros no se llama internamente "_open", sino "_open_r", asi con todas... vamos que la única cosa que se me ocurre es renombrar las funciones de syscalls.o hechas por Chui y añadirles "_r" :-?

Si tengo tiempo después lo intento y sus cuento

Un Saludo ^^

**Salustian** · 01/06/2007, 14:43

Lamento no poder ayudarte, has llegado a unos niveles en los que no puedo seguirte.

Ánimo y suerte. Estás haciendo un trabajo magnífico.

**kidchaos2k5** · 19/06/2007, 09:46

Iniciado por D_Skywalk

Un Saludo ^^

Por si a alguien le interesa:
Conseguí compilar el example2 de las x_gp32 y me funcionó correctamente, si no recuerdo mal hice lo siguiente:
1) Usar el devkitpro updater para actualizar la instalación (la verdad ya es que no lo se ni a que versión ni me importa)...
2) Volví a bajar las fuentes de las SDL y recompilé las x_gp32 arreglando los errores y añadiendo el flag de CYGWINa las defs

DEFS= -DSDL_USE_PTHREADS -DNO_SIGNAL_H -DENABLE_GP32 -DDISABLE_STDIO -DGP32 -D__INSIDE_CYGWIN__

3) En el example2: a) el fichero tada.wav no es reconocido por el SDL, pero probé otro y funcionó, b) no se porqué pero después de llamar a SDL_init se pierden los valores de los SDL_Audiospec, por lo que justo despues y antes de iniciar el audio los vuelvo a inicializar... y c) PlaySound("./gpmm/fichero.wav"); d) funciona!
Por cierto lo he subido directamente a la consola sin probarlo en el geepee así que a saber...

- Sigo teniendo mis dudas y cada vez me parece mas extraño, en el devkitpro, ya no se utiliza ld sino el gcc para el linkado, y los scripts de .ld y .x parecen bastante correctos pero al volver a probar el example2, modificando todo el makefile a la opción -specs=gp32.specs parece que incializa la LCD pero no se ve ninguna fuente por pantalla...

A alguien se le ocurrió programar con el RTEMS para la gp32?

Parecia bastante completito y el port del AW funcionó bastante bien...

@B^)>

**D_Skywalk** · 19/06/2007, 12:32

Iniciado por kidchaos2k5

1) Usar el devkitpro updater para actualizar la instalación (la verdad ya es que no lo se ni a que versión ni me importa)...

A mi si, si pones "gcc -v" te la dice, postéala anda

Iniciado por kidchaos2k5

2) Volví a bajar las fuentes de las SDL y recompilé las x_gp32 arreglando los errores y añadiendo el flag de CYGWINa las defs

DEFS= -DSDL_USE_PTHREADS -DNO_SIGNAL_H -DENABLE_GP32 -DDISABLE_STDIO -DGP32 -D__INSIDE_CYGWIN__

Ok, esos flags están bien pero sería más interesante que nombraras las libs con las que enlazas, o directamente pegar el makefile completo

Iniciado por kidchaos2k5

3) En el example2: a) el fichero tada.wav no es reconocido por el SDL, pero probé otro y funcionó, b) no se porqué pero después de llamar a SDL_init se pierden los valores de los SDL_Audiospec, por lo que justo despues y antes de iniciar el audio los vuelvo a inicializar... y c) PlaySound("./gpmm/fichero.wav"); d) funciona!

¿modificaste algo del syscalls.c?¿has añadido el x_gp32 a las libs?
No entiendo como te lee un fichero sin adaptar las funciones Fopen, etc...

Un Saludo y a ver si me puedes responder a todo esto y consigo replicar tu situación para hacer un tutorial/entorno actualizado para todo el mundo

**kidchaos2k5** · 19/06/2007, 13:05

Iniciado por D_Skywalk

A mi si, si pones "gcc -v" te la dice, postéala anda

$ arm-eabi-gcc -v
Using built-in specs.
Target: arm-eabi
Configured with: ../../gcc-4.1.1/configure --enable-languages=c,c++ --with-cpu=arm7tdmi --enable-interwork --enable-multilib --with-gcc --with-gnu-ld --with-gnu-as --disable-shared --disable-threads --disable-win32-registry --disable-nls --disable-debug --disable-libmudflap --disable-libssp --target=arm-eabi --with-newlib --prefix=e:/devkitPro/devkitARM
Thread model: single
gcc version 4.1.1 (devkitARM release 20)

Iniciado por D_Skywalk

Ok, esos flags están bien pero sería más interesante que nombraras las libs con las que enlazas, o directamente pegar el makefile completo

Código:

CC = arm-eabi-gcc
AR = arm-eabi-ar
AS = arm-eabi-as
LD = arm-eabi-gcc

TARGET = libx_gp32.a

all: $(TARGET)

DEFS= -DSDL_USE_PTHREADS -DNO_SIGNAL_H -DENABLE_GP32 -DDISABLE_STDIO -DGP32 -D__INSIDE_CYGWIN__

OPTFLAGS =-mtune=arm920 -march=armv4t -marm -mno-thumb-interwork -msoft-float -ffast-math -nostdlib -fno-common -ffreestanding -fno-builtin -fno-exceptions -mstructure-size-boundary=8 -O3 -fomit-frame-pointer -fstrict-aliasing -Wall

CFLAGS=-Iinclude -Isrc $(OPTFLAGS) $(DEFS)

#CFLAGS+=-DGP32_NEW_BLU

SRCS = \
        src/x_gp32_buf.c \
	src/x_gp32_conf.c \
	src/x_gp32_fat.c \
	src/x_gp32_io.c \
	src/x_gp32_lpt.c \
	src/x_gp32_uni.c \
	src/syscalls.c \
	src/x_gp32_dir.c \
	src/x_gp32_font.c \
	src/x_gp32_grafik.c \
	src/x_gp32_fnmatch.c \
	src/x_gp32_glob.c \
	src/x_gp32.c 

src/x_gp32_misc.o: src/x_gp32_misc.s
	$(CC) $(CFLAGS) $(OPTFLAGS) -o src/x_gp32_misc.o -c src/x_gp32_misc.s

OBJS = $(SRCS:.c=.o) src/x_gp32_misc.o

clean:
	rm -f $(OBJS)

$(TARGET) : $(OBJS)
	$(AR) d  $(TARGET) $(OBJS) exit.o
	$(AR) rcs $(TARGET) $(OBJS)

Iniciado por D_Skywalk

¿modificaste algo del syscalls.c?¿has añadido el x_gp32 a las libs?
No entiendo como te lee un fichero sin adaptar las funciones Fopen, etc...

El makefile del example2

Código:

#############	Generic Makefile

SYSTEMLIBS=	-lSDLx -lx_gp32 -lc -lgcc
SCRIPT=		arm-gp32bin.x

CC = arm-eabi-gcc
AR = arm-eabi-ar
AS = arm-eabi-as
LD = arm-eabi-ld
OBJCOPY=	arm-eabi-objcopy

B2FXEC =        b2fxec

INCDIR=		../include
SRCDIR=		./src
OBJDIR=		./obj

INCLUDES=	-I$(INCDIR) -I../../SDL-1.2.8/include -I/opt/gp32/arm-elf/include/SDL

###############	Program name

PROGRAM= example
#-fshort-enums
CFLAGS     =	-c -march=armv4t -marm -mno-thumb-interwork -msoft-float \
					-ffast-math -nostdlib -fno-common -ffreestanding \
					-fno-builtin -fno-exceptions -mstructure-size-boundary=8 -O3 \
					-fomit-frame-pointer -Wall -DGP32
LDFLAGS		=	-Map $(PROGRAM).map -nostartfiles --script $(SCRIPT) \
					-L../../ \
					-L../ \
					-L/c/devkitPRO/devkitARM/arm-eabi/lib \
					-L/c/devkitPRO/devkitARM/lib/gcc/arm-eabi/4.1.1
					#-L/opt/gp32/arm-elf/lib \
					#-L/opt/gp32/lib/gcc/arm-elf/3.4.1\

CFLAGS+=$(INCLUDES)

OBJS=			\
		example.o

###############	Rules to link

DOLINK = $(LD) $(LDFLAGS) crt0x_gp32.o $(OBJS) $(SYSTEMLIBS) -o $(PROGRAM).elf

###############	Rules to build program

.PHONY:	all clean $(PROGRAM)

all:	$(PROGRAM).fxe

$(PROGRAM).gxb: $(PROGRAM).elf
	$(OBJCOPY) -v -O binary $(PROGRAM).elf $(PROGRAM).gxb

clean:
	rm -f $(OBJS) crt0x_gp32.o $(PROGRAM).elf $(PROGRAM).gxb $(PROGRAM).map $(PROGRAM).fxe

$(PROGRAM).elf:	crt0x_gp32.o $(OBJS)
	$(DOLINK)

$(PROGRAM).fxe:  $(PROGRAM).gxb
	$(B2FXEC) $< $@

$(OBJDIR)/%.o:	$(SRCDIR)/%.c
	$(CC) $(INCLUDES) $(CFLAGS) -c $< -o $@

$(OBJDIR)/%.o:	$(SRCDIR)/%.s
	$(CC) $(INCLUDES) $(CFLAGS) -c $< -o $@

send: $(PROGRAM).gxb
	pclink -e $(PROGRAM).gxb

creo que no usa las de las x_gp32...

ME TENGO QUE IR, LUEGO LO COMPLETO!!!!!!

**D_Skywalk** · 19/06/2007, 16:50

Pero compañero estoy viendo que estas usando los examples de la libreria x_gp32, no?

Es normal que esas librerias funcionen (esas ya me funcionaban a mi), lo que no me funciona son los ejemplos de SDL, algo que muestre una imagen que tenga que cargar del disco, etc... :?

Un Saludo y bueno como tampoco has podido terminar el post, ya me lo aclaras aluego xD

**kidchaos2k5** · 19/06/2007, 17:12

Hola,

Sip, tenias razón, solo probé los ejemplos de la x_gp32 que cargaban wav y mods y que utilizan SDL/SDL_mixer en cada caso...

En el caso del ejemplo2 (cargar y reproducir un wav) de esta manera funciona linkando en el makefile así:

SYSTEMLIBS= -lSDLx -lx_gp32 -lc -lgcc

y en el código:

PlaySound("./gpmm/start.wav");

carga el wav y lo reproduce pero puede ser que utilice las funciones open de las libc del DKArm (creo)

SYSTEMLIBS= -lSDLx -lx_gp32 -lm -lg -lgcc

Si hago el linkado de esta manera, tambien compila correctamente, pero me da error al cargar el wav probando de todas las maneras (dev0:\\, gp:\\, .\)

Otra cosa que tampoco veo claro es el asunto de seguir usando los arm-gp32bin.x y crt0x_gp32.s, creo que sería mejor usar el -specs=gp32.spec al linkar, pero tambien hice pruebas que no funcionaron

...

En fin... Que sigo sin enterarme...

Saludos,

@B^)>