GP2X Porting For Beginners


rossimo

Still Fresh
Joined
Dec 16, 2005
Messages
15
What enviroment do most of the devs use to compile your work?

I have some C training. Lately, I've been trying to do a port of SDL Doom, but I cannot figure out how to get ARM binaries. I've heard you can just do someting like "./configure --target=arm-linux", but I still get x86. I have ARM gcc tools installed in linux. Is there something I must edit in the makefile? Puck (the guy who ported Exult) says he didn't even modify the source code. Is that how most of the porting works?

SDL Doom can be found at http://www.libsdl.org/projects/doom/.
 

gfoot

Member
Joined
Nov 15, 2005
Messages
218
In configure scripts, --target is only used for toolchains - it specifies the target architecture of the tool to build. You probably want to use --host, to specify the host architecture of the programs you're building. If your compiler is arm-linux-gcc, specify "--host arm-linux". Different toolchains have different prefixes though so check what yours is.

Sometimes you need to modify the code, usually either because you need to add hardware support for something or because you want to tailor the application to the system (e.g. control mappings). Generally you should find SDL handles the transition for you though.
 

rossimo

Still Fresh
Joined
Dec 16, 2005
Messages
15
Hhhm,, Getting there. I've edited the makefile to use arm-linux-gcc. But, now I'm getting errors such as:

arm-linux-gcc -g -O2 -I/usr/include/SDL -D_REENTRANT -o doom am_map.o d_items.o d_main.o d_net.o doomdef.o doomstat.o dstrings.o f_finale.o f_wipe.o g_game.o hu_lib.o hu_stuff.o i_main.o i_net.o i_sound.o i_system.o i_video.o info.o m_argv.o m_bbox.o m_cheat.o m_fixed.o m_menu.o m_misc.o m_random.o m_swap.o p_ceilng.o p_doors.o p_enemy.o p_floor.o p_inter.o p_lights.o p_map.o p_maputl.o p_mobj.o p_plats.o p_pspr.o p_saveg.o p_setup.o p_sight.o p_spec.o p_switch.o p_telept.o p_tick.o p_user.o r_bsp.o r_data.o r_draw.o r_main.o r_plane.o r_segs.o r_sky.o r_things.o s_sound.o sounds.o st_lib.o st_stuff.o tables.o v_video.o w_wad.o wi_stuff.o z_zone.o -lm -L/usr/arm/lib -lSDL -lpthread
i_sound.o: In function `I_StartSound':
/home/rossimo/GP2X/sdldoom-1.10/i_sound.c:413: undefined reference to `SDL_LockAudio'
/home/rossimo/GP2X/sdldoom-1.10/i_sound.c:413: relocation truncated to fit: R_ARM_PC24 SDL_LockAudio
/home/rossimo/GP2X/sdldoom-1.10/i_sound.c:415: undefined reference to `SDL_UnlockAudio'

....and so on. I'm guessing its just one directory that needs to be changed in the makefile to compile with. Anyone know?
 

gfoot

Member
Joined
Nov 15, 2005
Messages
218
Looks more like you're missing a library - you've got a symbol that's not defined in the libraries you're linking.
 

thingy88

Still Fresh
Joined
Dec 19, 2005
Messages
4
Location
Woking
Website
www.alanbroun.net
rossimo posted on Dec 25 2005 at 10:23 PM said:
Hhhm,, Getting there. I've edited the makefile to use arm-linux-gcc. But, now I'm getting errors such as:

arm-linux-gcc -g -O2 -I/usr/include/SDL -D_REENTRANT -o doom am_map.o d_items.o d_main.o d_net.o doomdef.o doomstat.o dstrings.o f_finale.o f_wipe.o g_game.o hu_lib.o hu_stuff.o i_main.o i_net.o i_sound.o i_system.o i_video.o info.o m_argv.o m_bbox.o m_cheat.o m_fixed.o m_menu.o m_misc.o m_random.o m_swap.o p_ceilng.o p_doors.o p_enemy.o p_floor.o p_inter.o p_lights.o p_map.o p_maputl.o p_mobj.o p_plats.o p_pspr.o p_saveg.o p_setup.o p_sight.o p_spec.o p_switch.o p_telept.o p_tick.o p_user.o r_bsp.o r_data.o r_draw.o r_main.o r_plane.o r_segs.o r_sky.o r_things.o s_sound.o sounds.o st_lib.o st_stuff.o tables.o v_video.o w_wad.o wi_stuff.o z_zone.o -lm -L/usr/arm/lib -lSDL -lpthread
i_sound.o: In function `I_StartSound':
/home/rossimo/GP2X/sdldoom-1.10/i_sound.c:413: undefined reference to `SDL_LockAudio'
/home/rossimo/GP2X/sdldoom-1.10/i_sound.c:413: relocation truncated to fit: R_ARM_PC24 SDL_LockAudio
/home/rossimo/GP2X/sdldoom-1.10/i_sound.c:415: undefined reference to `SDL_UnlockAudio'

....and so on. I'm guessing its just one directory that needs to be changed in the makefile to compile with. Anyone know?

It's best not to change the makefiles directly as these are auto generated for you by Automake. See GNU Autoconf, Automake and Libtool aka 'The Goat Book' for a good guide to the Autotools.

Instead, you change the way that a project is built via a combination of modifying environment variables and arguments to the 'configure' script. Run './configure --help' to see if there's anything obviously useful and then have a look at these evironment variables I've used when building my GP2X libraries for linux

Code:
# Adding tools to the path
HOST=arm-open2x-linux
TOOLS_ROOT=/home/thingy88/usr/open2x_gcc/gcc-4.0.2-glibc-2.3.5/arm-open2x-linux/bin
export PATH=$TOOLS_ROOT:$PATH

# Let the libraries find each other
LIB_ROOT=/home/thingy88/usr/open2x_gcc/gcc-4.0.2-glibc-2.3.5/arm-open2x-linux/arm-open2x-linux
export LDFLAGS=-L$LIB_ROOT

# Export the compiler to create ARM libs and the compiler for the build machine (your PC)
export CC=$HOST-gcc          # Equivilant to your arm-linux-gcc
export CC_FOR_BUILD=gcc

# Export your CFLAGS.
export CFLAGS=-msoft-float
export CXXFLAGS=$CFLAGS $CXXFLAGS
export CPPFLAGS=$CFLAGS $CPPFLAGS

# Lets your program find the main SDL library
export SDL_CONFIG=$LIB_ROOT/bin/$HOST-sdl-config

All the variables I've exported there are environment variables. Google for the ones you don't know about. Put any environment variables you think you need in a shell script and run it before running 'configure, make etc'. Make sure the script is run in the form '. /shell_script.sh' (Dot space) so that exported environment variables are kept.

Good luck and happy hacking! ;)
 
Last edited by a moderator:

rossimo

Still Fresh
Joined
Dec 16, 2005
Messages
15
HOLY CRAP. Something finally compiled.... Don't exactly know what is it though. I am now using the devkitgp2x. I compiled a doom executable using "./configure --host arm-linux" and make, then placed it into folder named "doom" in my SD card. I renamed the executable "doom.gpe". Then I placed the doom shareware wad in the same folder. When I ran it, all i got was a blank screen and the GP2X froze, I think. Question: Will the GP2X not do anything at all if its not a ARM executable? If so, since I got a frozen black screen, I did something right?? This is so ridiculous...

Thanks to the guys who have helped me so far.
 

gfoot

Member
Joined
Nov 15, 2005
Messages
218
You've probably linked dynamically (the default), and it's trying to link against the libc provided by GPH, which is not compatible with your toolchain.

Try this:

Code:
LDFLAGS=-static ./configure --host arm-linux

or hack the makefile and add -static to the linker command lines, if you can find them.

It is also possible to provide the shared libraries and point the loader to them using environment variables, but 9 times out of 10 it's easier to just link staticly from the start.

Edit: I'd also suggest leaving your executables with no extension, and writing wrapper shell scripts which run the executable then exec the gp2xmenu afterwards:

Code:
#!/bin/sh
./doom
sync
cd /usr/gp2x
exec ./gp2xmenu
 

rossimo

Still Fresh
Joined
Dec 16, 2005
Messages
15
Alright, STERM is awesome. I started it up and moved to my doom directory. After that, I ran the doom executable, then something actually happened. But, I got an error. Here is what showed up:

[root@Linux doom]$./doom.gpe

DOOM SHAREWARE STARTUP V1.10
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
Z_Init: Init zone memory allocation daemon.
W_Init: Init WADfiles.
adding ./doom1.wad
===========================================
SHAREWARE!
===========================================
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - [.Segmentation fault]

Then it returns me to the command line. I did the static linking as you told me, now I just got to figure out why it won't init the screen for playing. I thought this was a cool advancement. Any thoughts? Thanks for helping, gfoot and thingy88.
 

gfoot

Member
Joined
Nov 15, 2005
Messages
218
A segfault means it's accessing memory in a way it shouldn't. There's not much more you can say unless you instrument the code (put in more debug messages so you find out how many it hits before it falls over) or get a core dump and load it up in gdb. I think DJ Willis might be working on getting gdb to work, but until that's up and running you'll have to go printf crazy. :)
 
Top