Compiler Problems


jkgp2x

Still Fresh
Joined
Feb 7, 2006
Messages
32
i cant get my compiler to work correctly. I'm using Devcpp and i followed the directions that it said on the gp2x wiki and when i compile something it says it does not recognize the file format. Also what do i have to do to compile allegro games.
 
also id like to mention im kinda of newbie with C++. I know a little of it and can do basic stuff. Im learning it along with allegro because it seems to be easier then sdl. So any help with the compiler would be great.
 
I don't think we have Allegro libraries for the GP2X. Can you post the exact error message regardless?

Just a side question: How far are you in your C++ programming?
 
in the Full Devkit it says it comes with allegro libraries. The extent of my C++ knowledge is making text adventures.

The error i recieve is:
Compiler: devkitGP2X
Building Makefile: "C:\Documents and Settings\Owner\Desktop\project text game\Makefile.win"
Executing make...
make.exe -f "C:\Documents and Settings\Owner\Desktop\project text game\Makefile.win" all
arm-linux-g++.exe main.o -o "testcompile.exe" -L"C:/devkitGP2X/lib" -lalleg

C:/devkitGP2X/lib\liballeg.a(uptimer.o): In function `ptimer_thread_func':
uptimer.c:(.text+0x24): undefined reference to `pthread_sigmask'
C:/devkitGP2X/lib\liballeg.a(uptimer.o): In function `ptimer_init':
uptimer.c:(.text+0x16c): undefined reference to `pthread_create'
C:/devkitGP2X/lib\liballeg.a(uptimer.o): In function `ptimer_exit':
uptimer.c:(.text+0x1b4): undefined reference to `pthread_join'
C:/devkitGP2X/lib\liballeg.a(uthreads.o): In function `bg_man_pthreads_threadfunc':
uthreads.c:(.text+0x24): undefined reference to `pthread_sigmask'
C:/devkitGP2X/lib\liballeg.a(uthreads.o): In function `bg_man_pthreads_init':
uthreads.c:(.text+0x22c): undefined reference to `pthread_create'
C:/devkitGP2X/lib\liballeg.a(uthreads.o): In function `bg_man_pthreads_exit':
uthreads.c:(.text+0x2ac): undefined reference to `pthread_join'

make.exe: *** [testcompile.exe] Error 1

Execution terminated




so if someone could help that would be great. I'm still trying to learn this stuff and I have some good ideas for games.
 
I added the -lpthread onto my linker now i get another error.

Compiler: devkitGP2X
Building Makefile: "C:\Documents and Settings\Owner\Desktop\Makefile.win"
Executing make...
make.exe -f "C:\Documents and Settings\Owner\Desktop\Makefile.win" all
arm-linux-g++.exe -c "project text game/main.cpp" -o "project text game/main.o" -I"C:/devkitGP2X/lib/gcc/arm-linux/4.0.2/include" -I"C:/devkitGP2X/include/c++/4.0.2/backward" -I"C:/devkitGP2X/include/c++/4.0.2/arm-linux" -I"C:/devkitGP2X/include/c++/4.0.2" -I"C:/devkitGP2X/include"

arm-linux-g++.exe "project text game/main.o" -o "Project1.gpe" -L"C:/devkitGP2X/lib" -lalleg -lpthread

c:\devkitgp2x\bin\..\lib\gcc\arm-linux\4.0.2\..\..\..\..\arm-linux\bin\ld.exe: cannot find /usr/lib/ inside c:\devkitgp2x\arm-linux\bin\../../sysroot

make.exe: *** [Project1.gpe] Error 1

Execution terminated




what do i do about this one
 
That's most likely appearing because you don't have "-static", so it's trying to build it as a dynamic library setup.
 
Squidge posted on Apr 23 2006 at 07:56 AM said:
That's most likely appearing because you don't have "-static", so it's trying to build it as a dynamic library setup.
I think it might be worth pointing out the possibility that the fault is not because he is trying to link a shared object (which is really what we all ought to be aiming for) but that the reference in "sysroot/usr/lib/libpthread.so" is probably pointing to "/usr/lib" directory instead of the static-linked version of the library (i.e. try changing "GROUP ( /lib/libpthread.so.0 /usr/lib/ )" in that file to "GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )", and see if that helps, before resorting to a static link). This is probably what the actual source of the error is.

I know that telling the linker to compile using "-static" will probably fix it, but surely that's a workaround at the moment, not the solution, and I don't like the idea of encouraging new coders to link statically all the time, just because memory cards are getting cheaper... I'm relatively new to the GP2X myself, and I find it pretty horrific to have to link statically just to get a working build.

(Please don't get the wrong idea - Although it might not look like it from what I've said above, I'm really not trying to turn this into a static vs shared discusssion, I just think it's worth making the point that static linking is not an optimal strategy, especially in a RAM-restricted environment, such as exists on the GP2X.)
 
Last edited by a moderator:
The problem is that the standard Linux on the GP2X was all compiled with GCC2.95, and so the compiler he is using (4.0.2) will not be compatible with the default libraries on the gp2x, and therefore it is required to be statically linked to produce a working executable.

If you really want to use dynamic rather than static libraries, then you need to the last version of GCC that supports the libraries on the GP2X, which I think is 3.4 or thereabouts.

Don't forget however that dynamic linking means that the libraries must be present on whatever 2X you want to run the problem on, and so this means either you need to use only the GPH supplied SDL/etc or you need to install libraries on peoples 2X's (of which more and more are making there nand's readonly), or mess around with the LD library path variables which means running your programs from shell scripts. Add on top of this the number of different SDL builds we seem to be getting, as well as SDL extensions, and it's all starts getting very complicated.
 
Hi,

Squidge posted on Apr 23 2006 at 12:07 PM said:
Add on top of this the number of different SDL builds we seem to be getting, as well as SDL extensions, and it's all starts getting very complicated.

I know, I know, that's why I didn't want to get into this just yet. What we could try doing is setting LD_RUN_PATH to something like /mnt/sd/lib at compile time, and try and get everybody to have the latest libs in there. In theory, when the binary is run and the libraries linked at run-time, this directory should be the first place for it to look. I haven't got it to work 100% yet myself, but that's the goal I'm working towards. If it can work, I don't see why future firmware updates couldn't use the memory card as an alternate shared objects resource.
 
Last edited by a moderator:
Hi,

theoddbot posted on Apr 23 2006 at 12:46 PM said:
Open2x will ship with a full suite of gcc4 libraries, as well as the old libraries for compatibility. It seems to work fine so far, except for mplayer :/
I'd forgotten all about Open2X, thanks for the reminder. I'll check it out again!
 
Last edited by a moderator:
Thanks guys, adding -static worked and my demo got compiled. Now when i try to run it on my gp2x i just get a black screen. All my game uses is textout_ex() function and puts text on the screen. Is there a special way for initializing allegro for the gp2x or do i need to install something on my gp2x.
 
scorpio posted on Apr 23 2006 at 05:25 AM said:
I know, I know, that's why I didn't want to get into this just yet. What we could try doing is setting LD_RUN_PATH to something like /mnt/sd/lib at compile time, and try and get everybody to have the latest libs in there.
Just one comment that maybe not everybody will agree with: if I see some program that I think I'd like to check out, here's what I do: 1) Download the file. 2) Unzip it to a folder on an SD card. 3) Run the .gpe file on the gp2x. If it doesn't work, I'm outta here. Unless it's something that I REALLY want, I'm not going to go into a readme explaining which versions of some add-on package I have to have installed and where to put it. I just say "crappy software" and move on.

Is it fair? Probably not. But if you don't make your installs self-contained you lose everybody like me.
 
Last edited by a moderator:
Dzz: I'm exactly the same, I unpack to a spare dir, try and if it doesn't work, it gets deleted unless I really want to see it (and even then it gets about a 5 minute window before I get bored).

Shared libraries are nice if they are used by multiple programs, but considering that most of the time only one application will be running on the 2X anyway - so your not going to be saving anything apart from SD space, and I don't think it's worth losing the ease of installation and use just for that - eg. having to explain to a complete newb where to get all the latest libs and how to install them on all there SD cards, and then find out a week later a new lib is out and everyone needs to update again. You can't delete the old libs because earlier software may require them, and you eventually end up with a SD card full of libraries you dare not delete because your scared something may stop working... It begins to turn into Windows.. and don't get me started about the fact that when someone updates a lib, doesn't change the version number, but makes is incompatible with earlier software, so you need a dedicated sd card for software that needs that particular library version.

We never had to bother with various versions of various libraries on the GP32, and just linked everything static, (and the GP32 only had 8MB of RAM), so I don't see why we should have to do this on the 2X with 64MB of RAM just because it's almost capable of doing so (I'm not saying is capable because brand new GP2X's can't run dynamically linked GCC4 binaries, only GCC3.4 and below).
 
Hi,

Okay, I really didn't want it to go down this road, but I'll add my own opinion here, for what it's worth.

I can see where both of you of coming from when you say you want to be able to just unpack the program and run it. I can understand that, but why are we suggesting that the user has to worry about the libraries? We should be providing the libraries with the binary anyway - It's not as if it would make the whole package much bigger than if the binary was statically linked anyway. If the libraries are needed, OK, but if they're already installed, well there's some space saved, and they can be discarded.

If we used a standardised way of storing libs (which is what I was hinting at before) then the initial run of the program could install them there if they needed an update, and delete the ones that didn't need to be copied. By rights, GPH should be setting up the framework for this as part of the boot-up procedure. Maybe there should be a r/w partition of NAND mapped to /usr/lib or something like that, where the updated libs could be stored.

One of the ways I look at it is that for every statically-linked binary on my SD card, I lose space for at least one mp3 file that could be sitting on there.

Perhaps I'm looking back at my Amiga years through rose-tinted glasses, but it seems like the whole linux shared libraries thing is a mess, or perhaps it's GCC's revision control system which has messed things up. Updating libraries should be a no-risk proposition - [I've deleted some stuff here for brevity].

Squidge, the bit you said about somebody updating a lib but not the version number: What sort of person does that? They shouldn't be allowed near a computer, or they should at least be barred from distributing their code!

DZZ, I see what you're getting at, but there is something that I think is important: Just because the console doesn't have an easy-to-use text output interface, we should still be able to tell the user what the problem is, and be able to fix it. If that means writing code to check library dependencies, or writing a script to pre-load the required libraries, then I think we should do it. Not if it's holding back the next release of Vektar, of course, that's a special exception! :lol:

I think what I'm saying is that from my point of view, shared libraries should be the default way of doing things, and having to static link is the last resort. It could also be that since my background is not console programming, the assumption that my application is the only one running is somewhat alien to me, especially in a multi-tasking OS. It's just not something I'm happy with, and I don't think I can ever accept it as "normal".
 
I must agree with some of your comments, but your comment about losing space for a mp3 for each statically linked executable seems a little far fetched to me. The size of a statically linked binary compared to a dynamically linked library seems to be between 500KB - 1MB depending on what libraries are required. Most MP3 files are around the 4MB mark for decent quality ones.

Of course, if you can shave 4MB of an executable by going to a dynamically linked one, then fine, but for something like 500KB, I don't think it's worth it.

Still, once we have a system that actually works (coming along with Open2X hopefully), then it shouldn't be much problem to adjust the makefile of a project to spit out both a dynamic and static linked binary, and people can choose which they prefer - bigger size but ease of installation, or smaller size and possible library dependancy hell ;)
 
scorpio posted on Apr 24 2006 at 08:29 AM said:
If that means writing code to check library dependencies, or writing a script to pre-load the required libraries, then I think we should do it. Not if it's holding back the next release of Vektar, of course, that's a special exception! :lol:
Your ideas in this area are interesting and might be worth pursuing.

Vektar is 1.6MB, of which 1.1MB is sound effects and music. I don't think it's worthwhile trying to squeeze out the libraries that I do use.
 
Last edited by a moderator:
Hi,

Squidge posted on Apr 24 2006 at 05:47 PM said:
I must agree with some of your comments, but your comment about losing space for a mp3 for each statically linked executable seems a little far fetched to me. The size of a statically linked binary compared to a dynamically linked library seems to be between 500KB - 1MB depending on what libraries are required. Most MP3 files are around the 4MB mark for decent quality ones.
Yes, I think I went a little over the top there with my claims. I think one of the things that initially shocked me into investigating shared v static was the size of the original compo release of Vektar, it was something like 4.5MB.

Now, I know it's down quite a bit, but DZZ obviously knows what he's doing, unlike me, and I'm guessing that he's done a bit of work to get it down to that. There is quite a bit of knowledge needed about the various versions of GCC, compile options, etc., to be able to get executables sizes down to something decent. While it's interesting to spend time looking into the reasons why it happens, and how we can get around it, it's time that we should have been able to spend our own code.

Of course, if you can shave 4MB of an executable by going to a dynamically linked one, then fine, but for something like 500KB, I don't think it's worth it.
I'm thinking that as more and more people use cross-platform libraries like SDL which have so many features, there will be more and more baggage that gets linked in. Now I'm sure that the SDL libs can be built in such a way as to reduce bloat, and I believe a bit of work has already gone into this, but there is a lot of external code that people are using these days, and I've always felt a personal responsibility in this regard to take as little room as possible with my applications. There's probably a bit of a psychological factor of personal accountability in my attitude as well. I've always felt that the main portion of the executables that I've provided to people should be my work, and my code. While I can't guarantee that it'll always work as it should, I can at least say that it's mine, and if there's a problem, I can fix it. However, if 95% of my binary size is other people's code, how can I say with any degree of certainty that if there is a problem with it, that I can fix it?

At the moment I'm still coding things from scratch so as to teach myself from the ground up, so I can't say for sure how the sizes of things work out, but just from looking at my own current project, it's 500k static, and 50k dynamic (22k after stripping). I'm not taking external resources into consideration here, as they will be user-configurable and very much dependent on how things are set up on the SD card, but it's definitely guiding my thoughts in a certain direction...

Still, once we have a system that actually works (coming along with Open2X hopefully), then it shouldn't be much problem to adjust the makefile of a project to spit out both a dynamic and static linked binary, and people can choose which they prefer - bigger size but ease of installation, or smaller size and possible library dependancy hell ;)
It could be painful, I'll be the first to admit it, but the problem is that if we, as programmers, simply use static linking to cover up the system's shortcomings, then we're part of the problem. It's the sort of thing that could kill Linux in the long run, if this sort of thing goes unchecked.

jkgp2x, if you're still reading, I see you've started a new topic for your issues, and I'm sorry for leading things astray. I will load up the allegro libs tonight and try compiling something tomorrow to see if I can help out.
 
Last edited by a moderator:
scorpio posted on Apr 24 2006 at 02:53 PM said:
I think one of the things that initially shocked me into investigating shared v static was the size of the original compo release of Vektar, it was something like 4.5MB.
Heh, it shocked *me* into investigating the difference between WAV and OGG :lol:
 
Last edited by a moderator:
Back
Top