• Stephan Bergmann's avatar
    Switch Android armeabi-v7a to libc++/libc++abi/libunwind too · 312eeeee
    Stephan Bergmann yazdı
    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: 's avatarStephan Bergmann <sbergman@redhat.com>
    Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
    312eeeee
Adı
Son kayıt (commit)
Son güncelleme
..
compatibility.hxx Loading commit data...