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.
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.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.
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'd forgotten all about Open2X, thanks for the reminder. I'll check it out again!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 :/
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.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.
Your ideas in this area are interesting and might be worth pursuing.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:
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.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.
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?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.
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.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
Heh, it shocked *me* into investigating the difference between WAV and OGG :lol: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.