Difference between armeabi and armeabi-v7a

Question

As far as I can tell from the docs, the difference between the two supported flavors of ARM architecture in Android NDK is only in the set of supported CPU instructions. Is that really so? Is there no difference in calling conventions, or system call sequence, or something else?

I'm wondering what will happen if I compile a module to an ARM object file (with a compiler other than NDK - Free Pascal specifically), specifying ARMv6 as the architecture, and then link it to both armeabi and armeabi-v7a shared libraries. The FPC bits are not supposed to perform neither system calls nor Java calls, except via my own C-based interface.

EDIT: a hello world library, compiled with FPC for ARM, links and runs under ARMv7a emulator.

Solution

You definitely can run armeabi shared library on v7, and you can call its exported functions from another module. So, to be on the safe side, I would create a separate .so file from you Pascal code, sticking to armeabi (maybe with some C/C++ wrappers), and use this shared library with both your armeabi and armeabi-v7a libraries. The easiest way to load everything in correct order is to use

System.loadLibrary("pascal"); // armeabi
System.loadLibrary("c++"); // the platform will choose armeabi or armeabi-v7a

Comments

[zapl]

"I'm wondering what will happen" You could try :) No idea if that works, but the Internet suggests that there are ways to get Free Pascal code to run on Android.

[Seva Alekseyev]

Things like subtle EABI mismatches typically manifest on edge cases, as opposed to blowing up in your face right away. And performing coverage testing aiming for 100% is not something I'd undertake willy-nilly.

[Mark]

Bearing in mind this bug link, is it certain that mixing armeabi and armeabi-v7a works correctly?

[Alex Cohn]

@MarkCarter: I have never experienced this. As the linked report implies, there have always been unfortunate cases where the APK installer would not pick up libraries correctly from lib/armeabi and lib/armeabi-v7a folders. And I met some of them in person. The reported problem, though, does not look thoroughly investigated. Were both libraries present in the app-lib folder on the device? What did nm -D show regarding the missing functions?

[Mark]

AFAICT, the problem is when you have 2 independent libs A and B where A6, A7, B6, B7 represent compilations for different ABIs. However, only A6 and B7 supplied by vendor. I've experienced this: the lib loaded second will not load. Workaround was to put A6 (along with B7) in "armeabi-v7a" though I never tried it. I think that link is saying this workaround no longer works. A kind of no-longer-works-around :(

[Alex Cohn]

@MarkCarter: That's exactly what I'm talking about. In your scenario, you should have libs/armeabi/libA6.so and libs/armeabi/libB6.so and libs/armeabi-v7a/libA6.so and libs/armeabi-v7a/libB6.so. If you don't have libA6.so, then you cannot run your app on arm6, and don't need ``libs/armeabi/` at all. This workaround resolves installer problems only. The link does not truly convince me, it lacks very important details.