1

I built a library(.so) that is being called from JNI code in some android app. The JNI code is built using NDK.

If I build the library using android tool-chain, the library works well when called from JNI code.

If I build the library using another tool-chain (used on the same ARM device for none android applications), the library crashes when called from JNI code.

why do we need to use android tool-chain (or NDK) for compiling c/c++ code running in the context of an android app? why not use other tool-chains?

Improve this question
3
  • what other toolchain are you trying to use? Commented Oct 18, 2017 at 3:15
  • The other tool-chain is built using crosstool for ARMv7 and used for none-android apps on the device. Commented Oct 18, 2017 at 3:30
  • Why do you want to do this? It's a lot of work to do so and in the end you'll just have a subset of the NDK. Commented Oct 18, 2017 at 23:53

1 Answer 1

Reset to default
5

You can use other toolchains, but it requires special care.

Maybe a good starter would be to learn the UBERTC and Linaro Wiki.

The main difference is that NDK compilers are tuned for bionic (Android variant of C runtime libraries). Originally, bionic was a modest subset of Linux runtime. On latest platforms, most of the gap is closed, but now there are many extensions that you probably need.

Also, Android dynamic linker may require (depending on target platform) a set of ELF flags that are automatically delivered by NDK binutils, like PIC, id, and others.

It is quite possible to use arm-linux toolchain to build a statically linked executable that will run on Android, but for a library that must play well on the JNI environment the effort is probably not worth it.

Note that NDK provides tools to create a standalone toolchain, which behaves very similar to other toolchains you may be familiar with. This approach makes it easy to adopt 3rd-party libraries with sophisticated build scripts.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

While these are all valid points, I'm not sure they tell the whole story. Bionic uses the same function names (where the functions exist) as most other C libraries, so that potential problem is something the linker should fix up. You'll certainly need position-independent code (PIC) with modern Android releases, but even with the Google NDK toolchain you still have to pass command-line arguments to enable that. I'm not disagreeing with you, but I suspect other things are going on as well.
@KevinBoone sure, the manual titled How to Build an Android JNI Library with a non-NDK Toolchain and Avoid Ending in a Mental Hospital still begs to be written. Luckily, the OP only asked 'why?'.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.