|
It had been left out in 4082a18406c18af7b4fcef7bd501c3679c3be56b "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/64973
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
