summaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)AuthorFilesLines
2018-12-18No more need to generate lo.xcent from lo.xcent.inStephan Bergmann1-2/+0
...after fd34a19b4d8ccbd8740cf6056be87b8c267caaec "Seems that we don't need the com.apple.application-identifier after all" dropped the last @...@ replacement there Change-Id: Id6f4d1065b28be12e5d727bab553daa17fc4dfcb Reviewed-on: https://gerrit.libreoffice.org/65275 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-17kde5: remove older kde/tde plugins, and references to thatThorsten Behrens1-322/+0
KDE4 is out of maintenance upstream since Nov. 2014, and binaries provided by TDF have switched to KDE5 as the official backend. Change-Id: I165465b56d3ba3a18912b203c06ae8fc6111c0c9 Reviewed-on: https://gerrit.libreoffice.org/60014 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-12-13Introduce --enable-android-editingStephan Bergmann1-0/+10
...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: Stephan Bergmann <sbergman@redhat.com>
2018-12-13Switch Android armeabi-v7a to libc++/libc++abi/libunwind tooStephan Bergmann1-8/+0
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>
2018-12-11tdf#121925 test for URLClassPath.ClassPathURLCheckJan-Marek Glogowski1-0/+52
Adds a configure test to check for the enabled ClassPathURLCheck. Should be reverted, if our jars pass it. Change-Id: I040b41f329ccae21b92118fd58270682e50e95c1 Reviewed-on: https://gerrit.libreoffice.org/64709 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-08cross-compiling: no need for gtk or gstreamer for BUILDChristian Lohmaier1-0/+3
Change-Id: I34d2078e13119291efde85636d7c62555f10a55f
2018-12-08HAVE_CPP_ATTRIBUTE_NODISCARD is always true nowStephan Bergmann1-5/+4
...but for safety, leave the configure.ac check in for some longer. Also, save removing now-redundant SAL_WARN_UNUSED_RESULT in internal code for a follow-up commit. Change-Id: Ibe30b51c5cc4abc270f955c7c40b59f268986672 Reviewed-on: https://gerrit.libreoffice.org/64771 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_CXX_CWG1579_FIX is always true nowStephan Bergmann1-5/+4
...(according to <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579> it is fixed in C++14), but for safety, leave the configure.ac check in for some longer. Change-Id: Ibd2f0cac228117e35ac299e2fe74207394c900cd Reviewed-on: https://gerrit.libreoffice.org/64773 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_CPP_INLINE_VARIABLES is always true nowStephan Bergmann1-5/+4
...but for safety, leave the configure.ac check in for some longer. Also remove now-redundant SAL_INLINE_VARIABLE again (which was LIBO_INTERNAL_ONLY). Change-Id: Id049e0cb84b4f97f5859f1b16b867b39b448dec0 Reviewed-on: https://gerrit.libreoffice.org/64772 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_CPP_ATTRIBUTE_FALLTHROUGH is always true nowStephan Bergmann1-5/+4
...but for safety, leave the configure.ac check in for some longer. Also, save removing now-redundant SAL_FALLTHROUGH for a follow-up commit. Change-Id: I9bf42d237aea4c09459f28275568cf340e588607 Reviewed-on: https://gerrit.libreoffice.org/64770 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_CXX14_CONSTEXPR is always true nowStephan Bergmann1-6/+3
...but for safety, leave the configure.ac check in for some longer. o3tl::array_view::max_size (include/o3tl/array_view.hxx) and o3tl::basic_string_view::max_size (include/o3tl/string_view.hxx) started to produce loplugin:staticmethods warnings, which I silenced by /not/ making the functions static. Those classes are meant to be temporary drop-in replacements for standard classes (std::span slated for C++20, prev. std::array_view; and std::basic_string_view, resp.), so should have the same behavior as their standard counterparts (and making the functions static would likely cause loplugin:staticaccess warnings at call sites). Change-Id: If21674dbf02886f453ca447544e37b184df5a25e Reviewed-on: https://gerrit.libreoffice.org/64768 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_BROKEN_CONST_ITERATORS is always false nowStephan Bergmann1-12/+4
...but for safety, leave the configure.ac check in for some longer. Change-Id: Ife94cdfd56696edb113e32d84f563dd805e757e5 Reviewed-on: https://gerrit.libreoffice.org/64769 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07Use correct __cplusplus value with MSVCStephan Bergmann1-1/+1
...now that /Zc:__cplusplus is available in Visual Studio 2017 version 15.7 (see <https://blogs.msdn.microsoft.com/vcblog/2018/04/09/ msvc-now-correctly-reports-__cplusplus/>). Some external projects might run into issues when picking up /Zc:__cplusplus directly with $(CXXFLAGS_CXX11) or indirectly via $(gb_CXXFLAGS) now, but that appears not to be the case. Some obsolete MSVC-specific __cplusplus checks can be removed now. (The ones in external/libebook/libebook-msvc.patch.1 pick up /Zc:__cplusplus via $(gb_CXXFLAGS) in external/libebook/ExternalProject_libebook.mk.) Change-Id: Idc6849a0000ea424522f30f61caba112fae25d40 Reviewed-on: https://gerrit.libreoffice.org/64755 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07All supported versions of Clang and GCC support at least C++17 nowStephan Bergmann1-2/+2
Change-Id: I9130d0d1fceeb6efb1f324c99acd38eb92e67850 Reviewed-on: https://gerrit.libreoffice.org/64733 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06--enable-python=system no longer works on macOSStephan Bergmann1-11/+3
e.g.: > [CXX] pyuno/source/module/pyuno_callable.cxx > In file included from pyuno/source/module/pyuno_callable.cxx:19: > In file included from pyuno/source/module/pyuno_impl.hxx:27: > In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/Python.h:85: > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/unicodeobject.h:534:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister] > register PyObject *obj, /* Object */ > ^~~~~~~~~ (and some $enable_python=system/$_os=Darwin-specific code can thus be removed, too) Change-Id: Ic7901732c01bef9335c63dd6f0949453f5824226 Reviewed-on: https://gerrit.libreoffice.org/64732 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06Remove obsolete GCC version checksStephan Bergmann1-2/+2
...after <https://gerrit.libreoffice.org/63951> "Bump (Linux) GCC baseline to 7.0.0". (In some cases, those checks now need to check for __clang__, which was implicitly covered in the past by Clang consistently reporting to be GCC 4.2.1.) Change-Id: I860fef8c4ca41c22a7541f0fb2d34b37d1d69bed Reviewed-on: https://gerrit.libreoffice.org/63952 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06Bump (Linux) GCC baseline to 7.0.0Stephan Bergmann1-2/+2
...as discussed at <https://lists.freedesktop.org/archives/libreoffice/2018-November/081435.html> "minutes of ESC call ..." Change-Id: Ib1a4fdc56c51ab5c9e45173263689db2b88d72e7 Reviewed-on: https://gerrit.libreoffice.org/63951 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06Remove broken rebuild of compilerplugins when CLANG_FULL_VERSION changedStephan Bergmann1-2/+1
Not all compilerplugins/clang/*.cxx depend on config_clang.h (e.g., check.cxx doesn't), so this mechanism trying to rebuild compilerplugins once the underlying Clang installation changes doesn't work reliably in practice (just debugged through this with Miklos on IRC, and it wasn't the first time that `make distclean` fixed compilerplugins for somebody after they upgraded their Clang installation). Removing the brittle mechanism shows that plugin.hxx doesn't actually depend on config_clang.h. (There's a second mechanism trying to rebuild compilerplugins once the underlying Clang installation changes, namely > # Clang most probably doesn't maintain binary compatibility, so rebuild when clang changes. > $(CLANGOUTDIR)/clang-timestamp: $(CLANGDIR)/bin/clang$(CLANG_EXE_EXT) > $(QUIET)touch $@ in compilerplugins/Makefile-clang.mk, but that doesn't work reliably either, as it depends on the newly installed clang executable being newer than our clang-timestamp file, which will be the case for self-built Clang installations, but not necessarily when updating e.g. a distro-provided Clang installation.) Change-Id: Ie576f14356b3f0e55444375095c86aa851404bf3 Reviewed-on: https://gerrit.libreoffice.org/64623 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-05Jakarta Ant is actually called Apache AntGabor Kelemen1-3/+3
According to https://archive.apache.org/dist/ant/source/ it was renamed in version 1.5.2 (2003!) and we require 1.6.0 anyways Change-Id: I8adce0f67b9599249a3fb653779dad94539abff3 Reviewed-on: https://gerrit.libreoffice.org/64573 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-12-04Bump (Linux) Clang baseline to 5.0.2Stephan Bergmann1-26/+41
...as discussed at <https://lists.freedesktop.org/archives/libreoffice/2018-November/081435.html> "minutes of ESC call ...". This no longer sets CLANGVER, CLANG_VERSION, and CLANG_FULL_VERSION when using Apple Clang (on macOS), which uses different version numbers from upstream anyway. But those variables are only used in the context of compiler plugins, which do not work with Apple Clang anyway (which lacks necessary include files). (Also, move "AC_SUBST(COM_IS_CLANG)" up to where it belongs.) Change-Id: Iee37c42ecacf52fa5a07e35241bcd404025e1cdf Reviewed-on: https://gerrit.libreoffice.org/63899 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-29Rename Mac OS X to official name macOS in comments and documentationBartosz Kosiorek1-19/+19
Change-Id: I651b7f202fa52ff5f5357a11aa72c43eb7dc7f95 Reviewed-on: https://gerrit.libreoffice.org/64102 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2018-11-28On Windows, check for at least Visual Studio 2017 version 15.7Stephan Bergmann1-0/+9
...to further restrict the Windows MSVC baseline to not just VS 2017, but to the latest update (as the various updates bring significant improvements for C++11/ 14/17 support; see the mailing list thread starting at <https://lists.freedesktop.org/archives/libreoffice/2018-July/080588.html> "Compiler baselines (was: [Libreoffice-qa] minutes of ESC call ...)"). Change-Id: If6a1b62da1691ae8ae19edb4ed7b35e4b6e46501 Reviewed-on: https://gerrit.libreoffice.org/59209 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-28Require at least gperf 3.1, which no longer emits "register"Stephan Bergmann1-17/+7
...as discussed at <https://lists.freedesktop.org/archives/libreoffice/2018-November/081435.html> "minutes of ESC call ..." Change-Id: I47b6d4a7b8370262ca942b4385e2c0e6f0adc613 Reviewed-on: https://gerrit.libreoffice.org/63953 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-28Require at least flex 2.6.0, which no longer emits "register"Stephan Bergmann1-2/+2
...according to <https://github.com/westes/flex/blob/ 83d5d1695a2ab1d69ea4d8e7df27146c644876fc/NEWS>. Its use is no longer allowed in C++17, so will start to cause build failures once we restrict builds to at least C++17. (The situation with gperf is similar, but instead of checking for a minimal known-good version that no longer emits "register", we instead check for it indirectly in configure.ac, by creating gperf-produced conftest.inc and including that in the program used to test which -std= value to use. We could have done something similar for flex, but creating suitable flex output for inclusion might be more work than it was for the simple gperf case.) Change-Id: I662c6795ea5fde1420d9712c0ec910c0cadbc350 Reviewed-on: https://gerrit.libreoffice.org/63713 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-27Remove --enable-c++17 optionStephan Bergmann1-10/+1
...reverting 0f3b0ec973f06a98c75ef8acfa720a9973e4d2b5 "Avoid C++17 mode for Coverity Scan". As far as I understand, <https://lists.freedesktop.org/archives/libreoffice/2018-November/081454.html> "New Defects reported by Coverity Scan for LibreOffice" has been run against dd0e6849297c18aabe4fc29c0340a2ed1e474eaf "Temporarily drop --disable-c++17 from Coverity builds" but doesn't let issues like the one discussed at <https://lists.freedesktop.org/archives/libreoffice/2017-November/078966.html> "Re: New Defects reported by Coverity Scan for LibreOffice" reappear. So disabling C++17 for Coverity Scan builds appears to no longer be necessary. Change-Id: I22bfd9ad61da00e942a87aa5e1e0d1fab0004d49 Reviewed-on: https://gerrit.libreoffice.org/64121 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Jenkins
2018-11-27Bump minimum macOS run-time version to 10.10Tor Lillqvist1-21/+15
It is much over a year since we bumped to 10.9, so it is time. Bumping to 10.10 will allow us to with good conscience get rid of some code that (presumably) tries to emulate some aspects of OS X user interface look that went away in 10.10. See tdf#114839. Change-Id: Ic41f73d8e59a40c4696069af85bb3ff33146086c Reviewed-on: https://gerrit.libreoffice.org/63880 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-11-23Revert "Do use -O1 for Apple Clang older than 9.1.0"Stephan Bergmann1-1/+0
This reverts commit 55b9706bea5aa9b654ab39bc7d56339422e17087, which is obsoleted by b4f666f2e677b05cab8395fe7972b45b15f60c3f "Bump Xcode baseline to 9.3". Change-Id: Id2240351ed9495e311d55887b8e34f2aa776ae06 Reviewed-on: https://gerrit.libreoffice.org/63896 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-23Bump Xcode baseline to 9.3Stephan Bergmann1-0/+10
...as discussed at <https://lists.freedesktop.org/archives/libreoffice/2018-November/081435.html> "minutes of ESC call ..." Change-Id: I47e23d222b4b27256483dfd7de915dd99ae81317 Reviewed-on: https://gerrit.libreoffice.org/63878 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-23Bump compiler plugins Clang baseline to 5.0.2Stephan Bergmann1-2/+2
...as discussed at <https://lists.freedesktop.org/archives/libreoffice/2018-November/081435.html> "minutes of ESC call ..." Change-Id: Ia053da171d59747984546f38e19da808825b4f79 Reviewed-on: https://gerrit.libreoffice.org/63832 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-22Completely remove obsolete HAVE_BROKEN_STATIC_INITIALIZER_LIST checkStephan Bergmann1-34/+0
...after it had already been phased out almost two years ago with 721116c7ade10d76e3ed6832e3988c91427ba431 "Phase out support for HAVE_BROKEN_STATIC_INITIALIZER_LIST" Change-Id: Idfc216f10ecff9dab6a3218ba234d458d7816839 Reviewed-on: https://gerrit.libreoffice.org/63766 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-19Fix typosAndrea Gelmini1-5/+5
Change-Id: I0c966f517e337caa340526b48fa62b9910ce0a3e Reviewed-on: https://gerrit.libreoffice.org/63504 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2018-11-17bump product version to 6.3.0.0.alpha0+Christian Lohmaier1-1/+1
Change-Id: Ia9d5785fd32823e3c4f5b40fd3db1dc89d217bbe
2018-11-12bump hunspell to 1.7libreoffice-6-2-branch-pointLászló Németh1-1/+1
Change-Id: Ia8d1f4831e651b3a8d5115f78e5a5239b56c71c4 Reviewed-on: https://gerrit.libreoffice.org/63015 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2018-11-12Revert "Add check for en_US.utf8 locale"Stephan Bergmann1-8/+0
This reverts commit 6b56ca7a9bf67bcada666f4cb1c2e20e7c0d512e, which is no longer necessary after cfdcb1bb0cf3a9fa2b342109cd581d3211e965bf "external/libnumbertext: Don't depend on en_US.UTF-8 locale". I have seen a full `make check screenshot` succeed on a Debian 9 without any en_US locale. Change-Id: I2037af478d9bc5017c7263bb45effd3e9ccde0d3 Reviewed-on: https://gerrit.libreoffice.org/63279 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-09Fix creation/removal of GPG socketdirStephan Bergmann1-2/+1
<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 d7ecf4a4e37a9eeffa2b40f9fe5a2e6a8f90c876 "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 7a95ee8d0badb2cbbd137a6e18af1bada35ae933 "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/63181 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-09fix oss-fuzz buildCaolán McNamara1-1/+2
Change-Id: I22823323e0b4e15dbd6ea5f7efd35301995315bf
2018-11-08tdf#121131: Default COMPILER_PLUGINS_CXX to g++ -std=c++11Stephan Bergmann1-2/+2
ab8bf5533f8de9bb1aa9dc83e650e4eccf0fcac3 "Avoid error message from configure about clang's header for compiler plugins" caused problems after cd472d1d8489f30797f47d3f6dafede28c1feb90 "Compile as C++2a, where available", when the compiler used to build LO (CXX) supports -std=gnu++2a but the compiler used to build loplugin (COMPILER_PLUGINS_CXX) does not. So solve that problem instead by just adding -std=c++11 to the default for COMPILER_PLUGINS_CXX. Change-Id: I95e86bc28f2a0dfb2b7bdce6b15955b870428b8c Reviewed-on: https://gerrit.libreoffice.org/62997 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2018-11-06Don't default to only tango for iOSTor Lillqvist1-1/+0
It doesn't have all the images that dialogs need, for instance the vcl/res/radio1.png. Change-Id: If7839fecb2358846b92d46a47cce3b97f7556711
2018-11-05Package separate SVG icon setsJan-Marek Glogowski1-3/+4
This change packages all SVG based icon sets in seperate zip files. It automatically generates the SVGs links.txt from the non-SVG version, if it doesn't exists by 's/\.png/\.svg/g'. Same for the _dark version, but this just copies it. This would also work for a _dark_svg version, if needed. The patch explicitly does't package sifr_svg and tango_svg. Change-Id: I8d7fda42d0ff9a2108ba8406bd4e82af4c54ff0c Reviewed-on: https://gerrit.libreoffice.org/62706 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-11-02ENABLE_FIREBIRD_SDBC no defined in system-firebird caseCaolán McNamara1-4/+5
Change-Id: Ibfd5c7f0eb931faf00e40d349176237c12bfbdbf Reviewed-on: https://gerrit.libreoffice.org/62777 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-11-02Compile as C++2a, where availableStephan Bergmann1-1/+1
Change-Id: I6382be559a0c70d899d48d11e6f9b10ef270c9a4 Reviewed-on: https://gerrit.libreoffice.org/62744 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-01gbuild: rename value OS=IOS to OS=iOSMichael Stahl1-2/+2
This gets rid of the horrible hack in gbuild.mk to accomodate the case-incorrect iOS platform makefiles that cannot be renamed without upsetting git on file systems that sadly lack the case sensitivity feature. Keep the macro defined to IOS though. Change-Id: I1022bfef4900da00e75fc1ccce786b20f8673234 Reviewed-on: https://gerrit.libreoffice.org/62705 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2018-11-01Tweak stack protector checkKacper Kasper1-2/+2
* There were concerns that current program could fail if -Werror is enabled and incorrectly report stack protector availability. * Remove "return 0;" since configure adds it automatically. * Add -O0 to build options, otherwise the function is optimized away and it doesn't trigger linker failure. Change-Id: Ib540b583019d17fec1213ff3c364030b003a5f0f Reviewed-on: https://gerrit.libreoffice.org/60836 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-10-31Re-introduce the functionality to look for multiple iOS SDK versionsTor Lillqvist1-9/+3
Currently, look for 12.1, 12.0 and 11.4. (But of course I recommend people keep their Xcode updated, and thus now build against the 12.1 SDK.) Also get rid of two AC_SUBST variables that were not used anywhere. Change-Id: Ic1abf3eb1d900c843263dc781fd4c9a8ab126f09
2018-10-31Current iOS SDK is 12.1Tor Lillqvist1-1/+1
It sucks that configure.ac nowadays looks for exactly one specific version of the iOS SDK. I don't understand why that was thought to be a good idea. Change-Id: I5b67e17c627735bbafffc8177f1422813a33e034
2018-10-29Add check for en_US.utf8 localeMike Kaganski1-0/+8
Change-Id: I62ce7680c65ec49dd81085d4087c578f3b6c7907 Reviewed-on: https://gerrit.libreoffice.org/62508 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-10-22tdf#120176 - Text appears as white on first launchheiko tietze1-1/+1
Splash screen text should be black now Change-Id: I963ffc89c48fdc1de148586cd6f0fb4bf35d44bd Reviewed-on: https://gerrit.libreoffice.org/61924 Tested-by: Jenkins Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>
2018-10-22bump product version to 6.2.0.0.alpha1+Christian Lohmaier1-1/+1
Change-Id: If6dedb58b6918d9815c47f898a8b19eb9c0d5681
2018-10-20Upgrade to ICU 63.1Eike Rathke1-1/+1
Change-Id: I3b73fca39f51809f608dd78865c2566357a7b8a1 Reviewed-on: https://gerrit.libreoffice.org/62034 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2018-10-09make --enable-kde5 imply --enable-qt5Rene Engelhard1-6/+12
And explicitly fail if --enable-kde5 and --disable-qt5. Change-Id: Ifa0cef6b065ca0825b1cb42922f6fcf676e457f1 Reviewed-on: https://gerrit.libreoffice.org/61571 Tested-by: Jenkins Reviewed-by: Rene Engelhard <rene@debian.org> Tested-by: Rene Engelhard <rene@debian.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-01 01:04:37 +0000