Re: Android port problems

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.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot