Quoth Greg Ungerer: > Well in this sense there is no "libraries". You lost any notion of > them at the link stage. With no shared libraries all you have is > the final binaries. (Yes each will contain some of code that was in > the build library archives).
That's my point though. If linking to the libc statically gives an overhead of ~30KB to each program (which is about what it is with uClibc on m68k IIRC, at least with the options I was using), then if you have N binaries you're "wasting" (N-1)*30KB of flash space (this is *very* approximate, as different programs will link in different amounts of the libc, but there will usually be quite a bit of overlap). If flash space is limited, as N gets large (as you add diagnostic or scripting tools, for example) you start to run out of room. Whereas if you combine things, maybe you've now got M binaries (where M is small) each using ~50KB overhead (since your single program is now including more of the libc by combining otherwise separate functions). The waste is now (M-1)*50KB, but where N is significantly larger than M you're still saving flash space in the end. (Again, this is simplified.) (This also applies to other libraries as well, I'm just using the libc as an example because it's ubiquitous.) > Anytime you have "larger" RAM requirements you are much > more likely to hit memory fragmentation as a problem. True. > Small is better. It's a tradeoff. (Of course, in an ideal world, you'd just add more flash and then stick with small binaries. But that's not always possible.) _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
