1. 09 May, 2019 1 kayıt (commit)
  2. 07 May, 2019 1 kayıt (commit)
  3. 03 May, 2019 1 kayıt (commit)
    • Stephan Bergmann's avatar
      The -fvisibility-ms-compat hack is no longer needed for UBSan on Linux... · 9a7aa332
      Stephan Bergmann yazdı
      ...with latest Clang trunk towards Clang 9.  All the no-longer necessary hacks
      are made conditional on new NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY, which is
      still set for UBSan builds with older Clang on Linux (but which should
      eventually be purged).
      
      Various classes needed additional SAL_DLLPUBLIC_RTTI annotations, as building
      with UBSan instrumentation can generate references to RTTI symbols from
      additional places like outside a dynamic library that used to hide those symbols
      by default (but used to not hide them for old UBSan builds thanks to the
      -fvisibility-ms-compat hack).
      
      The odr-violation suppressions in solenv/sanitizers/asan-suppressions (which is
      not referenced from anywhere in the code base, but meant to be included in an
      ASan/UBSan build's ASAN_OPTIONS env var) are also no longer needed when
      NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY is false.
      
      Change-Id: I24ec3e388b0cbab50dbe2bf008d9569bff7bf25a
      Reviewed-on: https://gerrit.libreoffice.org/70829
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      9a7aa332
  4. 11 Nis, 2019 1 kayıt (commit)
    • Luboš Luňák's avatar
      merge --enable-selective-debuginfo into --enable-symbols · eeeec33a
      Luboš Luňák yazdı
      This got broken again due to confusion about the interaction between
      the various debug/symbol/whatever variables, so let's try to clean it
      up once more. So gb_SYMBOLS or any other global flag is no more.
      For checking whether a build target should get symbols, use
      gb_LinkTarget__symbols_enabled, which is internally controlled by
      gb_ENABLE_SYMBOLS_FOR (and flags from configure, command line or
      wherever affect that).
      
      This commit breaks the debug/nodebug split for PCH files, but fixing
      that is a relatively separate and complex change, so it'll be done
      in another commit.
      
      Change-Id: I6060dd38684445bb761e664344fb530386481332
      Reviewed-on: https://gerrit.libreoffice.org/70369
      Tested-by: Jenkins
      Reviewed-by: 's avatarLuboš Luňák <l.lunak@collabora.com>
      eeeec33a
  5. 22 Mar, 2019 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Allow to pass additional options into generator's clang::tooling · ad7e2af4
      Stephan Bergmann yazdı
      In my macOS build, that clang::tooling::runToolOnCodeWithArgs invocation failed
      to find headers like cassert and assert.h, which works now with
      
        COMPILER_PLUGINS_TOOLING_ARGS=-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -isystem /Users/stephan/Software/llvm/inst/include/c++/v1
      
      added to my autogen.input (I build against my Clang trunk libc++ whose headers
      are at /Users/stephan/Software/llvm/inst/include/c++/v1).
      
      Change-Id: Idbffa39c9fd4a88743fd498b8f7b6c9c56d7630d
      Reviewed-on: https://gerrit.libreoffice.org/69538
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      ad7e2af4
  6. 07 Mar, 2019 1 kayıt (commit)
  7. 24 Ock, 2019 1 kayıt (commit)
  8. 23 Ock, 2019 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Drop use of obsolete GCC -fno-default-inline · 1dcdb9b5
      Stephan Bergmann yazdı
      ...that is documented as: "Does nothing.  Preserved for backward compatibility."
      ever since <https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=160384> from
      2010.
      
      -fno-default-inline was the only value ever set in gb_DEBUG_CXXFLAGS, so the
      latter can be removed now.
      
      The use of gb_DEBUG_CXXFLAGS had accidentally already been removed from
      gb_LinkTarget__get_debugcxxflags with e751e242
      "--enable-optimized should be orthogonal to --enable-debug/--enable-dbgutil",
      and that leaves gb_LinkTarget__get_debugcflags and
      gb_LinkTarget__get_debugcxxflags with identical definitions, so replace those
      two with a single gb_LinkTarget__get_debugflags.
      
      Some external modules had used only gb_DEBUG_CXXFLAGS, when this was apparently
      meant to be used in addition to gb_DEBUG_CFLAGS, so those uses have been changed
      to gb_DEBUG_CFLAGS now.
      
      Change-Id: I84ea0ab1233569b0b02ca057240a71f138352381
      Reviewed-on: https://gerrit.libreoffice.org/66808
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      1dcdb9b5
  9. 21 Ock, 2019 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Slience bogus -Werror=maybe-uninitialized · fed7c3de
      Stephan Bergmann yazdı
      ...as emitted by at least GCC 8.2 with --enable-optimized, e.g. at:
      
      > In file included from include/rtl/ustring.hxx:37,
      >                  from include/cppuhelper/factory.hxx:26,
      >                  from unoxml/source/rdf/librdf_repository.hxx:24,
      >                  from unoxml/source/rdf/librdf_repository.cxx:20:
      > include/rtl/string.hxx: In static member function ‘static std::shared_ptr<{anonymous}::librdf_TypeConverter::Node> {anonymous}::librdf_TypeConverter::extractNode_NoLock(const com::sun::star::uno::Reference<com::sun::star::rdf::XNode>&)’:
      > include/rtl/string.hxx:294:27: error: ‘*((void*)(& type)+8).rtl::OString::pData’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      >          rtl_string_release( pData );
      >          ~~~~~~~~~~~~~~~~~~^~~~~~~~~
      > unoxml/source/rdf/librdf_repository.cxx:2094:30: note: ‘*((void*)(& type)+8).rtl::OString::pData’ was declared here
      >      boost::optional<OString> type;
      >                               ^~~~
      
      This appears to be a common pattern of false positives with uses of
      boost::optional, common enough to disable the warning globally for affected
      compilers, even if there would also be useful findings by that warning (e.g.,
      <https://gerrit.libreoffice.org/#/c/66619/> "Fix -Werror=maybe-uninitialized").
      
      I didn't bother to file a GCC bug for the reproducer used in configure.ac,
      <https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=maybe-uninitialized>
      already shows lots of open bugs in that area, and the documentation at
      <https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Warning-Options.html> states that
      "GCC may not be able to determine when the code is correct in spite of appearing
      to have an error."
      
      (Clang appears to not support -Wmaybe-uninitialized at all, so exclude it from
      the configure.ac check, to not have the check's failure result in an unsupported
      -Wno-maybe-uninitialized end up on the compiler command line.)
      
      Change-Id: Ifb9ca4c342750eae54f7e1a01506101310484c7e
      Reviewed-on: https://gerrit.libreoffice.org/66621
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      fed7c3de
  10. 29 Ara, 2018 1 kayıt (commit)
  11. 17 Ara, 2018 1 kayıt (commit)
  12. 13 Ara, 2018 1 kayıt (commit)
  13. 23 Kas, 2018 1 kayıt (commit)
  14. 09 Kas, 2018 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Fix creation/removal of GPG socketdir · f0305ec0
      Stephan Bergmann yazdı
      <https://gerrit.libreoffice.org/#/c/50978/> "gpg4libre: fix failing gpg test due
      to over-long filenames" had introduced the gb_CppunitTest_run_gpgconf target in
      xmlsecurity/CppunitTest_xmlsecurity_signing.mk, calling `gpgconf
      --craete-socketdir`.  A 2018-03-18 comment there notes that "Stephan's last
      comment: (and `gpgconf --remove-sockedir` be called after the test?) is not
      addressed yet, will do in follow-up commit".
      
      Follow-up d7ecf4a4 "properly check for gpgconf
      (and --create-socketdir) working" makes gb_CppunitTest_run_gpgconf conditional.
      However, in configure.ac,
      
        HAVE_GPGCONF_SOCKETDIR=TRUE
      
      is missing, so even after follow-up 7a95ee8d
      "actually add HAVE_GPGCONF_SOCKETDIR to config_host.mk.in...", config_host.mk
      will always contain
      
        export HAVE_GPGCONF_SOCKETDIR=
      
      so gb_CppunitTest_run_gpgconf will never be executed (and `pgconf
      --crate-socketdir` will never called).
      
      But even if it were executed, it would not create the socket dir that the test
      code in xmlsecurity/qa/unit/signing/signing.cxx is actually using, as
      gb_CppunitTest_run_gpgconf sets
      
        GNUPGHOME=.../workdir/CppunitTest/xmlsecurity_signing.test.user
      
      while xmlsecurity/qa/unit/signing/signing.cxx's SigningTest::setUp sets
      
        GNUPGHOME=.../workdir//CppunitTest/xmlsecurity_signing.test.user/
      
      and the GPG software is apparently picky about extra slashes when computing the
      socket dir name from the GNUPGHOME env var.
      
      (That `gpgconf --create-socketdir` was never executed with the current setup
      shows that calling it explicitly is probably not really needed, as the GPG
      software apparently creates it automatically on demand.)
      
      However, what is still missing is to remove the socket dir again (see the
      comment quoted above), and, probably more importantly, to exit any gpg-agent
      daemon operating on that socket dir that has (indirectly) been started by the
      tests in xmlsecurity/qa/unit/signing/signing.cxx.  At least with Fedora 29
      gpgconf from gnupg2-2.2.9-1.fc29.x86_64, that daemon is successfully terminated
      by calling `gpgconf --remove-socket`.
      
      So move the call to `gpgconf --create-socketdir` from the makefile to the test
      setup code (which makes it easier to guarantee that a single GNUPGHOME value,
      and thus a single socket dir, is used), and add a corresponding `gpgconf
      --remove-socketdir` call to the test shutdown code.  (As argued above, the
      `gpgconf --create-socketdir` call shouldn't be stricktly necessary, but it looks
      cleaner to do it explicitly anyway.)
      
      Change-Id: I2ec8f08943ed63ec27f8507461588ee7cdadf372
      Reviewed-on: https://gerrit.libreoffice.org/63181Reviewed-by: 's avatarThorsten Behrens <Thorsten.Behrens@CIB.de>
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      f0305ec0
  15. 31 Eki, 2018 1 kayıt (commit)
  16. 03 Eki, 2018 1 kayıt (commit)
  17. 12 Eyl, 2018 1 kayıt (commit)
  18. 28 Agu, 2018 1 kayıt (commit)
  19. 27 Agu, 2018 1 kayıt (commit)
  20. 26 Agu, 2018 1 kayıt (commit)
  21. 23 Agu, 2018 1 kayıt (commit)
    • Stephan Bergmann's avatar
      rhbz#1618703: Allow to use OpenSSL as backend for rtl/cipher.h · 4bc16aeb
      Stephan Bergmann yazdı
      ...with new configuration option --enable-cipher-openssl-backend
      
      rtl/cipher.h (which is part of the stable URE interface) offers functionality to
      en-/decrypt data with Blowfish in ECB, CBC, and streaming CFB mode, and with RC4
      (aka ARCFOUR; which is a stream cipher).  LO itself only uses Blowfish CFB and
      RC4, so only those are wired to OpenSSL for now, for simplicity.  Using Blowfish
      ECB and CBC, or Blowfish CFB in DirectionBoth mode would cause failures for now
      (cf. sal/qa/rtl/cipher/rtl_cipher.cxx); the assumption is that no external code
      actually makes use of this functionality.
      
      Using NSS instead of OpenSSL could be an alternative, but there appears to be no
      support in NSS for Blowfish in streaming CFB mode, only CKM_BLOWFISH_CBC for
      CBC mode.
      
      Change-Id: I0bc042961539ed46844c96cb1c808209578528a0
      Reviewed-on: https://gerrit.libreoffice.org/59428
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      4bc16aeb
  22. 08 Agu, 2018 1 kayıt (commit)
  23. 02 Agu, 2018 3 kayıt (commit)
  24. 04 Tem, 2018 3 kayıt (commit)
  25. 13 Haz, 2018 1 kayıt (commit)
  26. 29 May, 2018 1 kayıt (commit)
  27. 23 May, 2018 1 kayıt (commit)
  28. 03 May, 2018 3 kayıt (commit)
  29. 25 Nis, 2018 1 kayıt (commit)
    • Mike Kaganski's avatar
      Install UCRT from MSUs, not using nested VC Redist install · b8424437
      Mike Kaganski yazdı
      Using nested install is bad because (1) MS advises against it (though it
      most possibly doesn't relate to our specific case, when we install the
      vc redist exe package in UI part, so actually only a single MSI session
      is active at any time); (2) because it adds some extra interactions
      (user sees something "unrelated" being installed, which raises concerns;
      additional admin authentication required); and (3) because it runs in
      InstallUISequence, thus only installing the UCRT when doing interactive
      installation (unattended installs, including GPO, need to install UCRT
      separately).
      
      This patch aims to incorporate the original UCRT MSU (Windows Update)
      packages (https://support.microsoft.com/en-us/help/2999226) available as
      a zip archive from
      https://www.microsoft.com/en-us/download/details.aspx?id=48234
      - the same as used in VC redists for VS 2015 and 2017. This obsoletes
      the separate installation of the redist; since we also have the redist
      as merge module in our MSI, that is enough (and removes redundancy).
      The MSUs are installed using wusa.exe in a custom action (deferred,
      non-impersonating).
      
      As a small bonus, embedding MSUs instead of redist EXE allows us to
      shrink the size of installer a little (~10 MB).
      
      As deferred custom actions cannot access current installer database,
      we workaround this by using initial immediate impersonating action to
      extract the binaries into a temporary location. To ensure that the file
      gets removed upon completion (both successful and failed), we use an
      additional cleanup action.
      
      Commit 61b1d631 is effectively reverted.
      
      Change-Id: I1529356fdcc67ff24b232c01ddf8bb3a31bb00bd
      Reviewed-on: https://gerrit.libreoffice.org/52923Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarMike Kaganski <mike.kaganski@collabora.com>
      b8424437
  30. 20 Nis, 2018 1 kayıt (commit)
  31. 18 Nis, 2018 1 kayıt (commit)
  32. 12 Nis, 2018 1 kayıt (commit)
  33. 10 Nis, 2018 1 kayıt (commit)
  34. 18 Mar, 2018 1 kayıt (commit)