在运行时选择并加载备用共享库之一

Question

Was trying to add NEON support to an application, per the CPU-ARM-NEON.html in the docs. The docs mention runtime checks, but it turns out a native library cannot be both plain-v7a and NEON at the same time anyway, the runtime linker simply won't load such a library on some devices.

So it looks like I need two versions of the same library, optimized for different capabilities, to load one at runtime manually. Reportedly this can be done, though it is a step away from the ndk-through-eclipse path and I'm at loss on how to set things up.

I figured I list one of the versions under LOCAL_SHARED_LIBRARIES for the core to link properly, but then whatever I list there gets added to core dependencies. Runtime linker then checks for it to be present when I load the core, and throws even if another lib was already loaded in its place.

Also, the library that isn't listed remains unstripped and isn't automatically added to the package. I have to export unsigned apk from eclipse, add .so, sign, align and reinstall every time, which is bearable but far from practical.

Any suggestions on how to build the core binary without introducing a hardcoded dependency-by-module-name? Is there a civilized way to hook 'non-referenced' libraries up for packaging with the rest of the stuff?

---

Finally found the problem - had a mixed file with both neon and normal code built with .neon suffix. Apparently library can contain both NEON and plain-v7a code, a single file however can't - d32 instructions leak outside of neon execution paths and runtime linker does this:

D/dalvikvm(5323): Trying to load lib /data/data/com.my.app/lib/libapp.so 0x410b96e8
A/libc(5323): Fatal signal 4 (SIGILL) at 0x5c21ae92 (code=1)
D/dalvikvm(3908): GC_CONCURRENT freed 222K, 9% free 7010K/7687K, paused 38ms+2ms
I/DEBUG(91): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG(91): Build fingerprint: 'Lenovo/ThinkPadTablet/Indigo:4.0.3/ThinkPadTablet_A400_03/0070_0132_ROW:user/release-keys'
I/DEBUG(91): pid: 5323, tid: 5336  >>> com.my.app <<<
I/DEBUG(91): signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 5c21ae96
I/DEBUG(91):  r0 5c51d250  r1 00000000  r2 00000000  r3 00000000
I/DEBUG(91):  r4 00000000  r5 00000000  r6 00000000  r7 00000000
I/DEBUG(91):  r8 00000000  r9 3f800000  10 3f800000  fp 00000000
I/DEBUG(91):  ip 00000000  sp 5bc1c9d8  lr 5bf7423d  pc 5c21ae96  cpsr 40000070
I/DEBUG(91):  d0  3ef99342e0ee5069  d1  4012d97c7f3321d2
I/DEBUG(91):  d2  3f985a30f4230d02  d3  3fa55553e1053a42
I/DEBUG(91):  d4  543f7d0ef4230d02  d5  41d50fdf43800000
I/DEBUG(91):  d6  0000000000000000  d7  42c8000041f00000
I/DEBUG(91):  d8  0000000000000000  d9  0000000000000000
I/DEBUG(91):  d10 0000000000000000  d11 0000000000000000
I/DEBUG(91):  d12 0000000000000000  d13 0000000000000000
I/DEBUG(91):  d14 0000000000000000  d15 0000000000000000
I/DEBUG(91):  scr 80000012
I/DEBUG(91):          #00  pc 005fde96  /data/data/com.my.app/lib/libapp.so (_ZN4math7Matrix4C2Effffffffffffffff)

  5fde90:   eddd 0b0c   vldr    d16, [sp, #48]  ; 0x30
  5fde94:   eddd 1b0e   vldr    d17, [sp, #56]  ; 0x38
  5fde98:   f8cd 8028   str.w   r8, [sp, #40]   ; 0x28

Answer 1

If you want to be able to load one library or the other without having a dependency on the module name, it's probably easiest to avoid linking directly to that library, and just loading the right one at runtime and loading symbols from it dynamically using dlsym . If the library only has got a few functions/entry points, this shouldn't be too complicated. If, on the other hand, the library has got a very large interface (C++ libraries often tend to use lots of entry points, much harder to load with dlsym ), that's much harder.

Technically, if this wasn't limited to android, you could have two different versions of the library with identical names in different directories, and load the right one beforehand.

But in principle you shouldn't necessarily need two different versions of the library. You wrote:

but it turns out a native library cannot be both plain-v7a and NEON at the same time anyway, the runtime linker simply won't load such a library on some devices.

A library most certainly can contain both plain-v7a and NEON code, and should load on all armeabi-v7a devices - there are many such libraries out there. You just need to make sure that the common codepaths aren't built with NEON enabled, and that the internal NEON codepaths only are used after a runtime check. This requires that the library is designed with runtime-enabled SIMD-extensions in mind from the start, though - some libraries might be designed to decide on such things at compile time. And adding -mfpu=neon (or adding .neon to the filename in Android.mk ) to generic, non-SIMD code doesn't really add much measurable performance boost to normal code; at worst it will just insert a few instructions occasionally which will stop the code from running on other devices, without actually helping performance much.

The hello-neon sample in the NDK is a trivial example on how to handle this. Actual real-world libraries that do this are libav and OpenH264, to mention just a few.