It had been left out in 4082a184 "android: use
unified headers and llvm-c++ STL (x86) with NDK 16" because "arm unfortunately
crashes with llvm-c++, so keep with gnustl for now/fix that later".

Making armeabi-v7a work with libc++ etc. required a number of changes, listed
below, in this commit and in preceding ones.  At least 32-bit x86 already worked
with libc++ etc. prior to these changes in view mode, though it crashed in the
experimental editing mode (enabled with strippedUIEditing in
android/soruce/Makefile) as soon as one types in something,  But it is not
entirely clear to me why 32-bit x86 view mode didn't also fail similar to how I
saw armeabi-v7a fail.  (On 32-bit x86, these changes appear to neither improve
nor worsen the current state, view mode still appears to work fine while editing
still crashes upon typing anything.  With these changes, editing mode on
armeabi-v7a appears to work fine.  But I tested armeabi-v7a only with a real
device and 32-bit x86 only with an emulator, in case that might make a
difference.)

* Preceding <https://gerrit.libreoffice.org/#/c/64964/> "Move NSSLIBS to a more
  sensible place on the linker command line" plus this change's addition of
  -lunwind to the liblo-native-code.so linker command line make sure that
  liblo-native-code.so uses _Unwind_* functions from libunwind.a, instead of
  erroneously picking up the ones from libgcc.a that happen to be included in
  NSSLIB's nspr4 (-lgcc is automatically added to the end of the linker command
  line by the invoking compiler, that's how libgcc.a's _Unwind_* end up in
  NSSLIB's nspr4; it is neither clear to me why NSSLIB's nspr4, being a pure C
  library, uses _Unwind_* functions, nor why exception handling in
  liblo-native-code.so fails when using _Unwind_* functions from libgcc.a
  instead of from libunwind on armeabi-v7a, nor why that would work on 32-bit
  x86, but that's what I observed: ModuleManager::identify
  (framework/source/services/modulemanager.cxx) throws a
  css::lang::IllegalArgumentException, which calls __cxa_throw ->
  _Unwind_RaiseException, which ultimately lead to odd misbehavior and
  std::abort during stack unwinding when using _Unwind_RaiseException from
  libgcc.a instead of from libunwind).  (There is no libunwind.* in
  android-ndk-r16b for 32-bit x86 at least, so is presumably using _Unwind_*
  functions from libgcc.a.  It doesn't appear to make a difference if it
  indirectly uses those _Unwind_* functions from NSSLIB's nspr4, or directly
  from libgcc.a included in liblo-native-code.so if the

    $(if $(filter armeabi-v7a,$(ANDROID_APP_ABI)),-lunwind)

  had a ",-lgcc" else branch.)

* Preceding <https://gerrit.libreoffice.org/#/c/64965/> "Export RTTI symbols
  from liblo-native-code.so, for binary UNO bridge" makes sure that excpetions
  thrown from the binary UNO bridge can be caught by compiled catch clauses.
  Not sure why the corresponding state of
  bridges/source/cpp_uno/gcc3_linux_intel shouldn't have run into the same
  issue.

* Preceding <https://gerrit.libreoffice.org/#/c/64966/> "Adapt gcc3_linux_arm
  __cxa_exception to NDK 18 libc++abi" makes sure that our version of
  __cxa_exception matches the version from libc++abi.  This is clearly not
  relevant for 32-bit x86.  (The comment there android-ndk-r18b, but the
  additional member is already present in
  android-ndk-r16b/sources/cxx-stl/llvm-libc++abi/src/cxa_exception.hpp, too.)

The remainder of this change just drops old armeabi-v7a--specific workarounds
that are no longer needed/no longer work.

Change-Id: Ief4c2d562c5032abe6c3b94ca3b3394be6fcd4d3
Reviewed-on: https://gerrit.libreoffice.org/64973Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>