1. 17 Nis, 2019 1 kayıt (commit)
  2. 05 Nis, 2019 2 kayıt (commit)
  3. 03 Nis, 2019 1 kayıt (commit)
  4. 11 Mar, 2019 3 kayıt (commit)
  5. 18 Şub, 2019 1 kayıt (commit)
  6. 25 Ock, 2019 1 kayıt (commit)
  7. 13 Ara, 2018 4 kayıt (commit)
    • Stephan Bergmann's avatar
      Introduce --enable-android-editing · 25a0ae61
      Stephan Bergmann yazdı
      ...to select the experimental ...Editing... Android build variant.  (Ignored
      for non-Android builds, but using libo_FUZZ_ARG_ENABLE anyway, just in case.)
      
      Change-Id: I670925ff358039e38edc29db69f48a78d484f133
      Reviewed-on: https://gerrit.libreoffice.org/65077
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      25a0ae61
    • 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
    • Stephan Bergmann's avatar
      Export RTTI symbols from liblo-native-code.so, for binary UNO bridge · 357112d7
      Stephan Bergmann yazdı
      This will become important when switching armeabi-v7a to
      libc++/libc++abi/libunwind (coming soon) which uses address instead of string
      comparison when checking for type equality, so that exceptions thrown from the
      binary UNO bridge will need to use the exact same RTTI objects as referenced
      from the compiled catch clauses.
      
      Change-Id: If8bcb39212b5f5e154aee215cb5f471fe2dc4a7b
      Reviewed-on: https://gerrit.libreoffice.org/64965
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      357112d7
    • Stephan Bergmann's avatar
      Move NSSLIBS to a more sensible place on the linker command line · e465f9ae
      Stephan Bergmann yazdı
      511ae02c "Android: Enable HAVE_FEATURE_NSS and
      package the NSS libraries with apk" had added them to WHOLELIBS probably just
      because that already had the $(addprefix -l,...), even though --whole-archive
      doesn't make any sense for shared libraries.  Better place them later on the
      linker command line (after all our own archives and compiler support libraries),
      so that switching armeabi-v7a to libc++/libc++abi/libunwind (coming soon) will
      be able to override erroneously picking _Unwind_* symbols from NSSLIBS's nspr4
      instead of libunwind.
      
      Change-Id: Ie0c0b7a55da3eabe1bb427232d698b2a4af63e78
      Reviewed-on: https://gerrit.libreoffice.org/64964
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      e465f9ae
  8. 12 Ara, 2018 1 kayıt (commit)
  9. 13 Kas, 2018 1 kayıt (commit)
  10. 04 Kas, 2018 2 kayıt (commit)
  11. 02 Kas, 2018 6 kayıt (commit)
  12. 18 Eki, 2018 2 kayıt (commit)
  13. 06 Eki, 2018 1 kayıt (commit)
  14. 20 Agu, 2018 2 kayıt (commit)
  15. 15 Agu, 2018 1 kayıt (commit)
  16. 11 Agu, 2018 1 kayıt (commit)
  17. 07 Agu, 2018 4 kayıt (commit)
  18. 31 Tem, 2018 3 kayıt (commit)
  19. 15 Tem, 2018 1 kayıt (commit)
  20. 12 Tem, 2018 2 kayıt (commit)