Can you mix armeabi and armeabi-v7a libraries?

[webmonkey]

I have a big armeabi library that does not have any floating point
code, however it does depend on a smaller library that does have
performance critical floating point code. So I have compiled the
smaller library as a armeabi lib and as a armeabi-v7a lib. the
structure now looks like this:

libs/armeabi/libBig.so
libs/armeabi/libSmall.so
libs/armeabi-v7a/libSmall.so

But on a armeabi-v7a device it says it can't find the Big library. Is
there any way to make this work or am I required to compile the Big
library in armeabi-v7a as well?

[David Turner]

The package manager will only install the libraries from one of the libs/<abi>/ directory, depending on your device.

I'd recommend doing the following instead:

1/ Select only armeabi in your APP_ABI (or leave it undefined, this is the default)

2/ Build libBig.so and libSmall.so as armeabi libraries

3/ Build libSmallArmv7.so as an armeabi-v7a library. You can do that using by adding the following flags to its module definition:

LOCAL_CFLAGS += -march=armv7-a -mfloat-abi=softfp

LOCAL_LDLIBS += -Wl,--fix-cortex-a8

(these flags are described under docs/STANDALONE-TOOLCHAIN.html, in case you're curious).

This will ensure that your libSmallArmv7.so uses ARMv7-A CPU instructions. Note that the parameter-passing convention between armeabi and armeabi-v7a is compatible

(This is why -mfloat-abi=softfp is important, without it, your armeabi code would not be able to call your armeabi-v7a one if there are float or double parameters).

4/ Find a way in libBig.so to perform runtime CPU features probing (see docs/CPU-FEATURES.html) and call the functions in either libSmall.so or libSmallArmv7.so based on the result.

The three libraries will be installed on any armeabi or armeabi-v7a device, so please ensure that libSmallArmv7.so is not called by error on an armeabi one.

Voila, this is a bit of NDK voodoo, but it should work. The real hard part if doing 4/ properly.

This trick only works because both ABIs use the exact same toolchain. You can't do that to mix ARM and x86 binaries though :-)

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[webmonkey]

Hi David,

OK, I will try that. Thanks for the detailed instructions!

[webmonkey]

Hi David,

Instead of the CPU features probing in step 4 would it be safe to
check the Build.CPU_ABI property for "armeabi-v7a" in Java and pass
that on to the Big lib?

http://developer.android.com/reference/android/os/Build.html#CPU_ABI


And out of curiosity, since API level 8 there is also a Build.CPU_ABI2
property, what is that for?

Thanks

On Sep 2, 4:59 pm, David Turner <di...@android.com> wrote:

[David Turner]

On Mon, Sep 5, 2011 at 6:37 PM, webmonkey <webmo...@gmail.com> wrote:

Hi David,

Instead of the CPU features probing in step 4 would it be safe to
check the Build.CPU_ABI property for "armeabi-v7a" in Java and pass
that on to the Big lib?

http://developer.android.com/reference/android/os/Build.html#CPU_ABI

In theory that should work too. In practice some OEMs have been creative in their use of this property, so i'ts probably better to rely on the cpufeatures helper library instead.

And out of curiosity, since API level 8 there is also a Build.CPU_ABI2
property, what is that for?

This is to indicate that a given device supports two NDK ABIs. For example, any ARMv7-A based device would have "CPU_ABI" defined as "armeabi-v7a", and "CPU_ABI2" defined as "armeabi", because it is capable of running binaries for both of them. These values are reported by the Android Market client to the server, and helps filtering applications that can run on the target device when you use the Market app.