GP2X Help! Dev -c++

[deadlychicken22]

The pixel program is just an example of how to draw a pixel in sdl, so yes, it does use sdl, but I don't think it uses any of the others.... Could you please explain each of the linker commands that you said to add so that I know when I need them and when I don't?

Thanks,
-ben

 

[yaustar]

There are quite a few of those flags, here are the common ones

-Wall Enable all compiler warnings
-O Optimise generated code (for speed)
-O1 Optimise more
-O2 Optimise even more
-O3 Optimise fully
-s Strip all symbols for size

There are cases where if you optimise too much, it won't run, due to volatiles addresses or other factor.

In most IDEs, there are tick boxes and full explainations with them (at least in VS and CodeBlocks)

-lSDL is short for link libSDL from the libraries folder, for example you may not be using the image library functions so you don't need -lSDL_image and anything related to it (-ljpeg).

 

[buster2000]

why is it that when I follow digitaljez instructions everything works but I get a huge *.gpe file. I mean 2.5meg for a program that just tests a few simple SDL routines.
Is it because of using theoddbots SDL libs over the standard ones?

 

[dbilsborough]

why is it that when I follow digitaljez instructions everything works but I get a huge *.gpe file. I mean 2.5meg for a program that just tests a few simple SDL routines.
Is it because of using theoddbots SDL libs over the standard ones?

​

I get exactly the same thing

I'm sure it's an easy fix, these are the linker options I am using:

-static -lSDL_mixer -lSDL_ttf -lSDL_image -lmikmod -lvorbisidec -lfreetype -ljpeg -lpng12 -lz -lm -lSDL -lpthread

is this the problem?

 

[Mr.Jabberwocky]

The problem is that because we have to statically link, the entire SDL set of libs are being built into the program. I guess normally you would choose between jpeg and png, or mod and ogg and only include the relevant libs. But because this is a demo of SDL they all have to be built in. There is a compression program in EvilDragon's Archive that squishes it down a bit.

 

[dbilsborough]

The problem is that because we have to statically link, the entire SDL set of libs are being built into the program. I guess normally you would choose between jpeg and png, or mod and ogg and only include the relevant libs. But because this is a demo of SDL they all have to be built in. There is a compression program in EvilDragon's Archive that squishes it down a bit.

​

cheers,

I guess as it works fine it isn't a problem


I found webpage just after I posted (isn't it always the way!) it seems to suggest that a different linker might get a smaller file as the one I am using can't strip sections out:

http://aditsu.freeunixhost.com/dev-cpp-faq.html#largeexe

Why is the compiled executable file so large?
People usually ask this question when they compile a simple program which uses iostreams. The first thing you can do is to add -s to Project Options - Parameters - Linker, but the result may be still too large for your taste. In this case, either try to live with it (it actually doesn't matter so much!), or avoid iostreams (use cstdio), or use another compiler. Also note that there are some exe compressors on the net, e.g. upx.
The reason why iostream increases the size so much is that the linker links entire object files (from inside of libraries) if they contain at least one necessary reference, and the library for iostream is not well separated into small object files. Also, the linker should be able to link only certain sections of the object files (see "--gc-sections"), but this particular feature doesn't work yet on the mingw target (and that affects all libraries and object files).

 

[Mr.Jabberwocky]

I have totally lost my dev setup (hard drive died) and had never got round to trying adding -s. Does it make much of a difference ?
HeHe - so not only is it including all the code you are using - it is also including stuff you don't need. Thanks for the link - I will look at that later.

 

[dbilsborough]

I have totally lost my dev setup (hard drive died) and had never got round to trying adding -s. Does it make much of a difference ?
HeHe - so not only is it including all the code you are using - it is also including stuff you don't need. Thanks for the link - I will look at that later.

​

well -s takes the file I compiled from 2.5mb down to 1.7mb so a bit of an improvement.

 

[gfoot]

Static linking doesn't actually include everything - it does leave out object files within libraries if nothing in that file is actually referenced by any code that does need to be linked in. So you're not getting the whole of libc, or even the whole of SDL - just the bits you do reference.

Knowing that, you can avoid generic functions such as an image loading routine which chains to various other libraries to load different image types, and instead use dedicated functions to load different types of image - so you'll only link the functions you actually call. Similar issues come up with drivers - maybe SDL's audio can use OSS and ALSA, and autodetects at runtime which to use. If you can exclude the ALSA driver somehow, it won't need to be linked any more.

Still, 2.5Mb isn't that bad, and I've always said in these cases that you should stop worrying about what percentage of your executable is library code, and just write more of your own code to make up for it.

BTW, objdump is quite good for seeing how much of your executable comes from each library.

 

[Mr.Jabberwocky]

I understood dbilsborough's quote to be saying the libs are poorly implemented and so we end up with unreferenced functions. Having read it again there is nothing to suggest the SDL libs are the same. I stand corrected.
Now we have the source can it not be built so that we no longer have to statically link ?

 

[lucoxade]

digitaljez, I used your instructions along with the gp2x user guide instructions and I got it to compile with one warning and work on my gp2x! Thanks, now I just have to learn c and SDL (i started learning c++ a long time ago but I gave up and now i've forgotten it. All I can program in right now is visualbasic).

Here is the warning I get:

[warning] Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

Do you know what this means?


Thanks again,
-ben

EDIT: Ok, I tried to compile a hello world program from a tutorial on the wiki and I got the following errors:

unrecognized command line option "-fstart-group"
unrecognized command line option "-fend-group"

It says this twice, with "cc1plus.exe: error: " before each one. I don't know c/c++ or SDL and don't know what this means......
HERE is a link to the tutorial.

​

:huh: I'm getting the same problem,

/opt/local/devkitpro/devkitGP2X/bin/arm-linux-gcc -static -o valentine.gpe demo.c `/opt/local/gp2x/bin/arm-open2x-linux-sdl-config --libs` `/opt/local/gp2x/bin/arm-open2x-linux-sdl-config --cflags` -O2 -Wall -Werror
cc1: error: unrecognized command line option "-fstart-group"
cc1: error: unrecognized command line option "-fend-group"
cc1: error: unrecognized command line option "-fstart-group"
cc1: error: unrecognized command line option "-fend-group"
make: *** [valentine.gpe] Error 1

All was working ok before I installed oddbots SDL libs but now I can't find where fstart-group is coming from???? please help

 

[gfoot]

Presumably sdl-config uses -fstart-group and -fend-group to avoid having to specify the libraries in the correct order. I think they're linker-only options, so should be prefixed with "-Wl," but I can't say more, not being very familiar with sdl-config. Try running the sdl-config command on its own and seeing what it outputs. Just run:

/opt/local/gp2x/bin/arm-open2x-linux-sdl-config --libs

and post the output here if you like.

 

[lucoxade]

/opt/local/gp2x/bin/arm-open2x-linux-sdl-config --libs

​

gives,

-L/opt/local/devkitpro/devkitGP2X/lib -Wl,-rpath,/opt/local/devkitpro/devkitGP2X//lib -lSDL -lSDL_gfx --start-group -lSDL_ttf -lfreetype -lSDL --end-group -lSDL_image -ljpeg -lpng12 -lz --start-group -lSDL_mixer -lvorbisidec -lmikmod -lSDL --end-group -lgcc -lm -lc -lexpat -lpthread -ldl

 

[gfoot]

FWIW, my stock Debian Linux gcc, compiling natively, behaves in exactly the same way if I don't guard those options with "-Wl," so it's not a gp2x compiler issue specifically.

Anyway, it's clearly using these options, and as far as I can see they're linker-only, so should be prefixed with "-Wl," - i.e.

-Wl,--start-group ..... -Wl,--end-group

You could try making these changes to your copy of sdl-config - it wouldn't help other people running your makefiles etc though. It's a real shame though if the sdl-config scripts don't work, because when such things are set up properly by the library distributor, they really make life a lot easier for developers who no longer have to endlessly ask questions about which libraries and sublibraries they need to link in which order...

I'm kind of surprised though, I would have thought sdl-config would get this right, so I'm inclined to think I'm wrong here. If I am right though then it would be worth tracking down where this sdl-config came from, and maybe submitting a patch to their core version, if it suffers the same problem. As it stands, it would work fine if you only used these options when linking, so I guess it is possible that nobody has tried an all-in-one compile. Still feels unlikely.

 

[Deed]

It may be off topic, but what do you consider is the best c++ ide for windows : codeblocks or devcpp ?
I ask here, because, i heard from codeblocks here for the first time ...

 

[yaustar]

I prefer Codeblocks mainly because it is still actively updated and is a cross platform IDE although DevCpp seems to be a bit more user friendly.

 

[lucoxade]

Hmm well it seems --start-group was being translated as -fstart-group when run? Why would it do that? remove --start-group and no mor problems! yip yip

 

[gfoot]

Removing it might cause problems if the libraries enclosed really do reference each other recursively - be aware of that if you run into unresolved references in them in the future. It may be necessary to use -Wl,--start-group rather than just removing it completely.