4

I'm porting a big chunk of native code with several interdependent libraries. Loading the code fails since Android linker only looks dependencies in /system/lib/ and not in the application install directory at /data/data/com.packagename.nnn/lib.

As a first workaround I loaded all .so's from Java with System.load() in correct dependency order. This solution isn't satisfactory for me mostly because the set of libraries changes from build to build due to plugin architecture. Also the UI shouldn't need to know that much about native libs.

I've found that Android does not support RPATH or setting LD_LIBRARY_PATH for an app. The only workaround I found is building the libraries with fully qualified SONAMEs.

However some of the dependencies come pre-built.

  1. Is it possible compile fully qualified NEEDED tag into my own library even when the needed .so does not have fully qualified SONAME?

  2. Or is it possible to modify existing .so and replace its SONAME or NEEDED with fully qualified one without recompiling?

tsaarni
  • 818
  • 1
  • 8
  • 18
  • @tasaarni did you ever figure this out? I'm in DLL hell over almost this exact issue. My shared library dependency depends on libicu, which is included on many Android devices, but usually an older version that doesn't include symbols I need. So I've tried to specifically load the required libraries in correct dependency order (as per `ndk-depends`) - the new libicu seems to load ok in this way, but even then the depending library can't seem to find the symbols it needs. Is there a step I'm missing? – ephemer Dec 23 '15 at 17:15

1 Answers1

0

Mozilla Fennec loads a bunch of shared objects from a custom cache directory under their /data/data/package/ directory, you might take a look at their source.

NuSkooler
  • 5,391
  • 1
  • 34
  • 58
  • Thanks for your answer! I see that they've put **a lot** of effort to loading. They've even implemented their own modified version of the [linker](http://hg.mozilla.org/mozilla-central/file/0664108eb19d/other-licenses/android/linker.c)! They could have fixed the path issue in that but for me it seems they still do [hard-coded loading of dependencies](http://hg.mozilla.org/mozilla-central/file/0664108eb19d/other-licenses/android/APKOpen.cpp#l651). – tsaarni Sep 02 '11 at 15:18