Hi Tor, Thanks for the nice summary :-)
On Thu, 2012-05-17 at 12:22 +0300, Tor Lillqvist wrote: > libraries into fewer. There is an option for that already, > --enable-mergelibs, that merges quite a large number of them into one, > libmergedlo.so. This works only for libraries in gbuildified modules, > built in tail_build. ... > Anyway, this indeed has helped a lot. But not enough. I am not sure if > the number of libraries merged this way can be easily increased much > at this stage of gbuildification. IIRC the gbuild-ification work is continuing apace, and my hope was that the two davids, matus & others' work on the large number of gbuild_* git branches would get merged - and unblock tail_build so that it can incorporate many more of the libraries that are already gnu-makeized which in turn would help us getting much more into libmerged ... That at least is my hope: David ? what's the plan there :-) hopefully that good stuff is all going in somewhat before the 3.6 feature-freeze ? Then again - the linking speedup from merging all that lot together has an upper bound of ~7% CPU time in 3.5.4 (at least for me), though there'd be potentially useful size savings, improved optimisations etc. > 1) One way would be to identify libraries that are used only by one > other library, and then merge those. Unfortunately doing this > uncoditionally (on all platforms) encounters quite some stop energy. Hopefully not :-) if we can show that there is some pointless split, I don't see why we can't merge things. Of course, there are a number of existing divisions that are perhaps worthwhile / necessary to keep: URE vs. non-URE, GUI & non-GUI, but beyond that - IMHO merging makes sense [ though I'd be happier to see it done with static libraries, rather than wholesale code movement perhaps ;-]. > So it would have to be done conditionally just for Android Clearly we want to share as much as possible with libmerged I guess, and that work sounds generally useful. > 2) Another way would be to start using another dynamic linker, namely > the one Mozilla uses on Android, known as "faulty.lib" for some > reason. See https://github.com/glandium/faulty.lib . It doesn't have > the silly limitation on the number of shared libraries. > > Unfortunately, it brings in another problem: It doesn't handle text > relocations. How do Mozilla get away without any text relocations ? and/or - why are we re-locating .text - it sounds profoundly crazy :-) surely that is readonly. Is there a better toolchain to use ? > Of course, linking all required code into one shared object means that > this linking will take quite some time, especially if debugging > information has been included. Nasty indeed; unclear what we can do here, beyond profiling and/or begging the linker guys :-) Of course, continuing to have a non-merged option for rapid development where it is not necessary seems important to me; and perhaps CPU's or L3 cache-sizes will save us in the end ;-) HTH, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice