LibreOffice Android bootstrap

[Tor Lillqvist]

(Reply Cc:ed to LO development list with Guillaume's permission.)

>> While searching some infos about the problem that I have I found one
>> of your commit in LibreOffice [1].
>> So I write you to know if you can tell me more about this commit. What
>> does this patch does to solve the problem to load shared libraries
>> properly?

>> [1]
>> http://cgit.freedesktop.org/libreoffice/core/commit/sal/android/lo-bootstrap.c?id=5510127e89d6971a219ce3664e4631d6c6dda2b1

Here is what I recall...

1) The Android run-time dynamic linker (the code that implements
dlopen() etc) in its C library ("bionic") has a relatively low limit
on the number of shared libraries opened: 128. This is a problem for
LO, but hopefully not really for your application... I think LO is a
bit unique in being (normally) split into such a large number of
dynamically loaded libraries. We currently try to get around this by
simply combining these libraries into a smaller number. But this is
not really something we need code for.

2) Unlike System.loadLibrary() on the Java side, dlopen() doesn't
search the app's "lib" folder. So it's simplest and safest to make
sure to pass a full absolute path to the library to be loaded.

3) dlopen() doesn't look for dependent libraries recursively. (Or at
least not in the app's "lib" folder, as mentioned in the previous
point.) Additionally, once loading of a .so has failed, even if you
after that load more dependent libraries and try again, it remembers
that loading that library failed last time and won't try again, even
if it would succeed better this time... So you should not call
dlopen() unless you are sure all dependent libraries have already been
loaded. So the code in our lo_dlopen() traverses the library's ELF
import data and recursively loads needed libraries first before
calling the system dlopen().

--tml