How to correctly support different C++ STL's in Android Native Builds

Issue

To be honest, i understood that all c++ dependencies must be compiled with same C++ STL & Ndk in Android Project as indicated here. but what if i have many dependencies with supporting different C++ STL and NDK versions. It sounds like no use of it. I believe that there must be accurate way for it.

Firstly, the situation is that there is an android project which builds with many c++ libraries (might be more than 3). Those are supports different C++ STL and Ndk. Somehow those dependencies was working until decided re-build for some purposes. Such as building old version of v8(v4.9) support stlport , POCO supports gnustl and etc.

By the way i already tried;

• Building dependencies with certain STL (failed)
• Adding different STL's as Shared Libraries to dependencies such as (Android.mk);

    include $(CLEAR_VARS)
LOCAL_MODULE := stlportshared
LOCAL_SRC_FILES := $(LOCAL_PATH)/../../../src/main/jniLibs/$(TARGET_ARCH_ABI)/libstlport_shared.so
include $(PREBUILT_SHARED_LIBRARY)

include $(CLEAR_VARS)
ifeq ($(TARGET_ARCH_ABI),x86)
    LOCAL_SRC_FILES := $(LOCAL_PATH)/../../../libsnative/x86/release/libv8-7dc15a4d5e.a
else
    LOCAL_SRC_FILES := $(LOCAL_PATH)/../../../libsnative/armeabi/release/libv8-7dc15a4d5e.a
endif
LOCAL_MODULE := v8
LOCAL_SHARED_LIBRARIES := stlportshared
include $(PREBUILT_STATIC_LIBRARY)

Actual APP_STL is gnustl_shared in Application.mk

Note: There is a no compile error but runtime crashes. Crash is null dereferences . Intended to ask as superficial but i can forward details of crashes for who are curious.

Solution

First of all, there are very strong reasons to use the latest release of NDK. r20 at the time of writing this, and this luckily only has two STL variants supported: c++_shared and c++_static.

The easiest way to organize your native libraries is to build them all with c++_shared.

I understand that you have encountered some problems with this approach. Fixing these problems may be helpful in the long run, because these problems may be symptoms of some internal troubles in your code.

But if you cannot, don't dispair.

Your app can safely use different mative libraries, each built with its own STL, as long as it does not mix these native libs. If you have Java class A that has native methods in libA.so and class B with its own libB.so, and there are no calls from libA.so to libB.so or vice versa, you should not care which STL is used by libA.so and which - by libB.so.

Furthermore, if you have native library libQ.so that calls C functions in libP.so, then you don't care whether libP or libQ use STL at all, or which STL each of them uses. But this is true if these C functions are not C++ functions in disguise. They should not pass C++ objects (including std::string). They should not receive or return pointers to C++ objects (even if the C API uses reinterpret_cast for void *.

Note that for most practical purposes, the rules for libraries built with c++_static are same. Two such libraries should not pass C++ objects from one to the other.

Answered By - Alex Cohn