GP2X Native Arm Toolchain On Gp2x

[crusty]

Has anyone tried to run gcc on the GP2X directly?

The serial port access (either GPIO or USB gadget) provides
terminal access and 200 mhz cpu speed is more than fast
enough for compiling.

Just thought I would ask.

 

[sand_man]

It should work but I see no reason to. It would take too long to compile large programs.

 

[theoddbot]

gcc can chew a lot of ram at times. I'm not sure how well this would work. If you really want to develop on the gp2x, just use python

 

[BradN]

It might be half workable with a boot hack to make linux use all 64MB of RAM...

 

[Radek]

I'd rather like to see integrated assembler/debugger with an editor. It should work fast and would allow much faster developing and experimenting with GP2x hardware.

 

[Klepto]

I'd rather like to see integrated assembler/debugger with an editor. It should work fast and would allow much faster developing and experimenting with GP2x hardware.

​

YES PLEASE!

I'm playing around with something which may become a native toolchain of sorts. It's Forth not c so it may not be useful for most people, however it will include an assembler. Don't expect a release anytime soon, I'm learning as I go and doing it all for my own amusement

 

[theoddbot]

Well for an editor vi is already on there. If anyone has other suggestions I'll look at integrating them. nano is a possibility.

 

[cheap-plastic]

Nano and joe would be very useful. I often get stuck in vi on the gp2x... :lol:

 

[torpor]

i've called for an ARM-native port of gcc and all the syslibs (and the kernelpack, and /bins') that can be compiled on the gp2x, by the gp2x (i.e. making the gp2x entirely self-hosting) since before the GP2X was released ...

it'll happen. for sure!

/glances at his 60gig USB datatank ..

 

[Kitsu]

This would also be very useful once there is a good GP2X emulator (if it can run > 266Mhz). No wierd cross compiling, and the speed of a multi GHz proccesser should make development/testing a bit easier!
This would also solve my Python distutils woes...

 

[Mudi]

There shouldn't be any difference in the executables produced by the cross-compiler and the native-compiler, so running it through a GP2X emulator would be pretty silly.

What I want to see on the GP2X is a memory debugging util ala Valgrind... I've got a bug in a program where it segfaults when I free an SDL_RWops on
GP2X but x86 valgrind says there isn't any problem (it runs fine on PC btw)

 

[Kitsu]

There shouldn't be any difference in the executables produced by the cross-compiler and the native-compiler...

Except the environment/tools/libs available at compile time. Distutils are very sensitive to the environment they (and their Python) are run in. Also They run a bunch of tests on the resulting binaries... which all fail when you cross-compile (or so I've read my google research, I haven't even gotten them looking in the right place yet ).

I can see how there would be less advantage for everyone else though, just cross compiling then testing in an emulator would be quicker and just as easy.

 

[pcklee123]

Well for an editor vi is already on there. If anyone has other suggestions I'll look at integrating them. nano is a possibility.

​

I like midnight commander http://www.ibiblio.org/mc/. But you need glib (1.2.10) ftp://ftp.gtk.org/pub/gtk/v1.2/ to compile mc.

 

[luteijn]

What I want to see on the GP2X is a memory debugging util ala Valgrind... I've

It's not valgrind, but will at least help when you're accessing your heap (malloc'd) memory wrong.
Electric Fence helps you detect two common programming bugs:
software that overruns the boundaries of a malloc() memory
allocation, and software that touches a memory allocation that has been
released by free(). Unlike other malloc() debuggers, Electric Fence will
detect read accesses as well as writes, and it will pinpoint the exact instruction that
causes an error.

You might have freed the memory before, just not realise it. Link with -efence:

http://luteijn.xs4all.nl/html/gp2x/efence/....13/libefence.a

 

[pcklee123]

There shouldn't be any difference in the executables produced by the cross-compiler and the native-compiler...

Except the environment/tools/libs available at compile time. Distutils are very sensitive to the environment they (and their Python) are run in. Also They run a bunch of tests on the resulting binaries... which all fail when you cross-compile (or so I've read my google research, I haven't even gotten them looking in the right place yet ).

I can see how there would be less advantage for everyone else though, just cross compiling then testing in an emulator would be quicker and just as easy.

​

I've been using qemu-arm to run some programs while compiling eg basiliskii needs to generate cpu code from a program halfway through compiling. i suppose it might be possible to build the whole toolchain using oopo's script in qemu-arm. it would be possible to just copy that into the gp2x.
Scratchbox also uses qemu-arm i tthink
l

 

[TKF15H]

Sorry for bumping an oldish topic, but here is a native GCC for the Zaurus. If anybody still needs a C compiler on the gp2x, this should do the job, right?