When mixed development of modules using different C + + support libraries, throwing exceptions is not normal, throwing exceptions leads to a SIGSEGV

If you use GCC to compile gnumake for a subset of modules, these compile the dynamic libraries using the project under the Gradle compilation framework. Then there is the possibility of a problem in the topic, when a mixed development of a module using a different C + + Support Library is thrown abnormally.

When we use Gnumake compiled projects for porting and compiling, we use the corresponding GCC toolchains under the NDK to compile and link to the corresponding C + + support library. However, Gradle (or Android Studio) uses Clang by default and is determined to link to the LLVM corresponding libc++ support library.

In my case, I chose Ice-3.7 for porting, and the tools are somewhat incompatible with NDK-GCC and gnustl,ice-3.7 support for LLVM and STLport.

My development project was developed using the C + + support features of the Android Studio 2.3 version later. and Gradle even the combination of cmake, but has been completely biased towards the LLVM (clang). Despite the cost of the Build.gradle modify the cmake corresponding parameters, so that cmake to use GCC instead of clang, but still seems to ignore my cppflags '-std=gnu++11 ', Gradle generated by the native dynamic library is dependent on libc ++.so. Cause the following situation

native.so ==> libc++.so

==> ice.so

ice.so ==> libgnustl_shared.so

But the actual operation, the ice.so inside the abnormal related symbols __cxa_*** chain to native.so, and __gnu_unwind*** chain to libc++.so. But not libgnustl_shared.so.

In this way, in the run when the ice.so inside throws the exception into the libc++.so, which caused the SIGSEGV anomaly, really let a person collapse, if you do not understand, I was collapsed one day.

The solution is to let the ice.so of the exception-related functions linked to the LIBGNUSTL support library, since it is not possible to solve the dynamic load, then use LIBGNUSTL_STATIC.A good. After doing this, the problem is resolved.

Crash exception function link error:

Using the C + + static support library, the problem is resolved after the correct run path:

When mixed development of modules using different C + + support libraries, throwing exceptions is not normal, throwing exceptions leads to a SIGSEGV