Simple(ish) Porting


TooDice

Still Fresh
Joined
Oct 15, 2006
Messages
2
I'm interested in getting into programming for the GP2X and have had a play, compiled a few programs using sdl which was pretty new to me, and generally had a bit of fun with it. I know my way around C programming to a certain extent and have dabbled with C++ in the past. However, I've always used the likes of msvc++ and never really bothered with linux much. I've used linux and I'm reasonably confident with the way that things work, but only recently have I started to fall in love with it.

MinSys is ace. I've had problems with cygwin in the past and this is how I thought cygwin was going to work in the first place. Now all I want to do is get my head around compiling things with gcc, but I'm struggling. Msvc++ hides these things away from the user in a way and I've been sheltered from it. Simple programs are fine, but almost anything with a configure script seems to fail.

I've always dived into other people's code in order to learn and am already good friends with google. I reckon that if I can start attempting to compile a port that doesn't present too many problems, just enough to get me thinking, I could learn a great deal.

Has anyone ported anything that turned out to be pretty easy? I'm not looking to do anything worth releasing just yet, I only want to get to grips with my new development environment and learn a thing or two about cross compiling so it doesn't matter if it's already been done. I'm not asking for your source code either, if you had to modify it, because that's all part of the problem I'm going to have to get my head around.

Cheers,
TooDice
 
For configure scripts, cygwin is your friend... you just have to get the initial configuration of cygwin correct or it doesn't work right.

Most SDL programs can be ported as long as they don't use OpenGL or x86 assembler. There probably are still a good few of those programs out there.
 
never had any problems with cygwin. the only issue to be aware of is cygin calling apps outside of cygwin. eg: if you have ruby in windows, having cygwin stuff call ruby will quickly barf with path errors and other things. you need ruby in cygwin if you want to use ruby from within it etc...

other than that, never had any problems with cygwin.
 
If you're looking for a (moderate) level of isolation from Makefiles and calling gcc directly, Dev-C++ on Windows works pretty nicely I have to say. It's *fairly* simple also switching between a Win32 and a GP2X build of the same software (for the same project of course) - You just need to set up the GP2X toolchain as a new Compiler Suite under Dev-C++.

Under Linux, I've also had good success using NetBeans 5.5 with the "CND" C-Compiler Plugin, although this will typically mean setting up a "GP2X" build profile *per-project* (specifying the new paths to the compiler/libraries etc), although if you're really brave, I'm sure that you can edit the configuration XML to add GP2X as a new compiler suite - not for the faint hearted though!

Tony
 
It's probably worth me having another look at cygwin when I've got more time to play with it.

I found a small, uncomplicated game on sourceforge and got it to compile using minsys after a bit of fiddling. I ran into one problem though and had to use an untidy work-around.

Am I right in thinking that using "LIBDIR = /c/devkitgp2x/lib" should allow the compiler to find the required libraries? It still threw up an error after setting this when trying to find libSDL.a (using -lSDL). I had to put the full path to the library in the line with the compiler which seems a bit unnecessary.

It'll do for now though.

Also, the game crashes horribly when run on the GP2X. I haven't modified any of the actual C code yet so it's to be expected. I just wondered if there's any way to get some info back as to why it crashed. Is there any software that I can use that'll spit out an error message or will I just have to trace through the source by hand until I spot something that I know it won't like?

Cheers for the help!
TooDice
 
Generally to make the linker look for libraries in an "additional" location use the "-L" switch with the location you want the linker to look. For your example:
-L /c/devkitgp2x/lib

Of course this switch should be in the command line that links the executable. To debug the code you can "telnet" to the gp2x and then run the application from the command line so you can see stdout and stderr but if it's crashing here might not be mush you can look at. If you compile/link your code with debug (switch -g on compile and link you can use gdb on the gp2x or gdbserver and insight/gdb running on you development box to debug the code over TCP/IP. This setup is not difficult to get working but does require you to put the pieces together. If you check out the devkitPRO stuff on source forge you will see that they are going to add GP2X to their supported toolchain. This will allow some nice setup and support for the developement arena. I use this toolchain for PSP, DS and GBA development today. I am trying to get it to work for ipod (ARM cpu) but the testing enviornment is pretty bad there.
 
Back
Top