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