Android port problems

[Tor Lillqvist]

As some of you might know, the system dynamic linker on Android
(which, like all the Android user level runtime, is not related at all
to the one on desktop (GNU/)Linux) has a silly limitation on the
number of shared object (dynamic libraries) that can be in use: 128.
Given that the number of system libraries used by a typical process
running LO code is already a few dozens, there is definitely not
enough "slots" available for the dynamic libraries used during running
of typical LO code that loads documents.

OK, the above is nothing new, has been known for some time already. So
something has to be done. One way forward is to merge many of the LO
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. There might also some other limitations, I don't
recall. Unfortunately the GNU linker isn't exactly known for its
blazing speed, so especially if you are building with debugging
information, linking libmerged can take quite long (depending on your
build machine). At one point, when my Linux laptop for some reason had
decided to keep its CPU speed throttled at the lowest, it took hours;)

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.

So what other ways forward?

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.
So it would have to be done conditionally just for Android (or using
the same condition that currently is used for libmerged). Will make
makefiles messy. Still, could be the easiest solution, although how
much such merging can be realistically done, whether enough, is
unclear.

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. The Android NDK produces shared libraries that contain
text relocations. Apparently there is just one such relocation in
each, and it isn't the fault of the toolchain as such, but one of the
C runtime objects linked in to shared libraries contains non-PIC code.
See http://code.google.com/p/android/issues/detail?id=23203 .

3) A third way would be to just stop using such a large number of
shared libraries, and build the LO code as static archives, do static
linking of UNO components, as we have to do for iOS anyway, so there
is some code to take care of the related complications already. (See
ifdefs for DISABLE_DYNLOADING.)

On iOS the code of an app is a single executable program (that links
only to system libraries dynamically), on Android a LO code -using app
would have, in this case then, a single shared library (that also
links only to system libraries dynamically).

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. (This is true for an iOS build, too,
even if it doesn't use the GNU linker. There it is the "dsymutil"
phase that extracts debugging information from the objects and
collects it into file(s) in a separate .dSYM directory that takes the
most time. Others have noticed, too, this might be interesting at some
stage: http://src.chromium.org/svn/trunk/src/build/mac/strip_save_dsym
)

--tml