26

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.

Seva Alekseyev
  • 59,826
  • 25
  • 160
  • 281
  • "I'm wondering what will happen" You could try :) No idea if that works, but the Internet [suggests](http://wiki.lazarus.freepascal.org/Custom_Drawn_Interface/Android#Configuring_the_Free_Pascal_Compiler_for_Android) that there are ways to get Free Pascal code to run on Android. – zapl Aug 31 '12 at 16:50
  • 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. – Seva Alekseyev Aug 31 '12 at 16:58

1 Answers1

9

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
Alex Cohn
  • 56,089
  • 9
  • 113
  • 307
  • Bearing in mind this bug [link](https://code.google.com/p/android/issues/detail?id=62796), is it certain that mixing armeabi and armeabi-v7a works correctly? – Mark Jan 29 '15 at 02:44
  • @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? – Alex Cohn Jan 29 '15 at 06:45
  • 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 :( – Mark Jan 29 '15 at 11:01
  • 1
    @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](https://code.google.com/p/android/issues/detail?id=62796) does not truly convince me, it lacks very important details. – Alex Cohn Jan 29 '15 at 11:32