General Problem With Oopo Toolchain (newbie Coder)

[Tomcat]

I'm pretty new to C and GP2X coding, but I already managed to compile and run some stuff some weeks ago.

Now, some things in GP2X development have changed, so I set up a new toolchain, the one from ooPo (wasn't available when I first tried developing in December). It works quite well, only I don't get how I should work with the libraries...

paeryn's hw-sdls are not installed on my GP2X, so after using those for my sample program I understood that I have to copy them over to my SD card and use LD_LIBRARY_PATH to use them. So far so good.

Now my sample program crashed with "libc.so.6: version 'GLIBC_2.3' not found, required by ./lib/libSDL-1.2.so.0". Checked /lib and /usr/lib on my GP2X, seems like paeryn's libSDL needs the libc 2.3.5 that comes with ooPo's toolchain, not the 2.2.something I got on my GP2X... but I don't believe you guys copy over all of the libs to your SD card just to run your own compiled stuff?

After some more tries of doing exactly that, I gave up because I'm always missing some lib or have the wrong version. I think I'm doing something fundamentally wrong... are the libs on my GP2X outdated (all firmware upgrades went through perfectly, so I doubt that)? Should I have installed the ones that come with the toolchain installer? Am I missing something in compiling or linking (I read up on statically linking because I don't do this currently, but the little software engineering I know tells me it shouldn't matter)...

Help is greatly appreciated. If I should've read some FAQ or manual or something, don't hesitate to tell me... something's quite wrong here. Thanks!

 

[luteijn]

-static

P.

(link statically, it's the only way to be sure.. Use the above option when linking)

 

[Tomcat]

-static

​

I think it worked, no idea though... my own sample program compiles well, but crashes immediately with a black screen on the GP2X. I tried the wiki demo code then, same effect. No idea if there's an error message because sterm only shows a black screen (with cursor line and ability to input characters), then locks up when I quit it.

I'll try adding some printf statement to the code, maybe I can find something.

But thanks so far.

 

[Tomcat]

No... won't work.

Here's what I do. I got this code: Demo program

gp2x-gcc `/usr/local/gp2xdev/bin/sdl-config --cflags` -O2 -Wall -Werror -c -o a.o demo.c

gp2x-g++ -static -o a.gpe a.o `/usr/local/gp2xdev/bin/sdl-config --libs`

gp2x-strip a.gpe

Then I start it on the GP2X using:

LD_LIBRARY_PATH=./lib ./a.gpe

(./lib contains all libSDL files)

Most of the compilation options come from here: Demo program

Adding printfs to the code or trying to retrieve the stdoud/stderror from the shell have resulted in empty files. I don't have a serial cable to see the console.

All that happens is that I get a black screen, after which sterm seems to come back (I can type stuff), but it crashes when I try to exit.

 

[gfoot]

If you don't have a serial cable, you could still use the USB gadget serial drivers - http://www.glost.eclipse.co.uk/gfoot/gp2x/

If you want to return to the menu on exiting, you need to exec it, because that's what it did to you. This only applies when you're run from the menu though. Generally I'd recommend not giving your executable the .gpe extension, and supplying a .gpe shell script which runs your program and then execs the gp2xmenu afterwards. Then you can still run it from sterm or a serial link without it chaining the menu all the time.

Finally, if your executable really is hanging the system, the kernel filesystem buffers won't get flushed, so your debug files will be empty. In this kind of case, after each output it's worth fflushing the output file (even if it's stdout or stderr) and calling sync(). Calling sync() in particular slows your code down a lot, so it's worth turning off sync calls unless you're actually debugging a hard crash.

That's academic though, if you set up the gadget serial driver - in that case, just fflush and don't bother syncing, and you'll probably be ok.

 

[paeryn]

If you're using my version of SDL then you don't copy it to your GP2X, it has to be statically linked.
Try changing the link command to
gp2x-g++ -static -o a.gpe a.o `/usr/local/gp2xdev/bin/sdl-config --static-libs`
That should add the extra bits needed to link properly.

If you're using sterm then you really aught to re-direct stdout & stderr to files as whenever sterm prints anything it'll overwrite your screen. It may even still respond to joystick movement & button presses whilst your app is running.

 

[Tomcat]

Thanks for your suggestions.

I changed the code, added some debug lines, also added the stuff to make it flush and sync...

Now, the code does run, but the --static-libs for sdl-config doesn't make a difference: I still get a black screen, like a crash. I'm now running a bash script directly from the GP2X menu.

Checking the messages my code wrote to the file, it seems that it's crashing in this line:

screen = SDL_SetVideoMode(320, 240, 16, SDL_SWSURFACE);

A debug line directly above still gets printed out, the line directly after doesn't. Which means the code is not even able to check the status of the screen variable (which would tell if SetVideoMode failed). I changed SWSURFACE to HWSURFACE once because this is HW SDL, but no change. Any other ideas?

 

[lemon]

Well, at least last week paeryn's SDL libraries were broken. I did some tests and had to revert to using theoddbot's (non accelerated) libraries again. I hope paeryn can do a new release which works again

 

[Voyageur]

You can also try the test release of Paeryn's SDL libs, found in this thread.

I don't have any black screen problem with it

 

[lemon]

You can also try the test release of Paeryn's SDL libs, found in this thread.

I don't have any black screen problem with it

​

Mmm, oopo's script should be updated to use this SDL version then...