This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> Not in crosstool-NG, but you can configure uClibc to build only the > static libraries. Perhaps that is the key. > > But beware. If you are really size-constrained, and you have many > programs, > then static linking could make your file system grow. True, though there are only a dozen or so functions being called, and most of these are __syscall() defined in the libs, so not much there (for example, pthread_create()). > > If you have many programs on your file system, and those programs > call many > of the C libraryu functions, then those functiopns bodies will be > duplicated > into every program that uses it. Which will make your file system > grow. Now, > if you have a single program, then static linking could be a > solution. YMMV. Taking the BusyBox approach -- all the apps will have xxxx_main() so that we can use a single binary -- thus we have no duplication AND, we only have 4 apps and most share code ANYWAY, so the BB way will reduce many bytes of shared code (I hope). > > But there are other options. > > For example, there is a script called mklibs that will scan your > file system > for every executable programs, list all UNDefined symbols in them, > search > for those symbols in every shared libraries. Then for each shared > library, > it will try to recreate that library from the static version, but > only with > the symbols listed before. Rince and repeat until there are no more > any > UNDefined symbols. Field updates are the main reason for NOT doing something like this. I don't even want to go there ;). > > Of course, if the static version of the library does not exist, > then the > shared library is used as-is, as there is no way to remove function > bodies > (or other objects, for that matters) from a shared library. > > That way, you get the best of both worlds: > - space gained using shared libs > - space gained from including only required symbols > > You can find a version of mklibs in different places: buildroot, > debian... > Google is your friend there... > > I am also planning on adding such a script (perhaps mklibs itself) > to > crosstool-NG, along with populate. > > Regards, > Yann E. MORIN. I'll try the "build only static libs" approach. Thanks! Andy -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |