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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
