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.