summaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2019-10-16bump product version to 6.4.0.0.alpha1+Christian Lohmaier
Change-Id: I4eaf798b1b43fe8a78d1697d9ebc207ff8ace492
2019-10-15move HAVE_FEATURE_DESKTOP/OPENCL to their dedicated headersLuboš Luňák
HAVE_FEATURE_OPENCL is included by a common Calc header and HAVE_FEATURE_DESKTOP is included by a common Writer header, causing pretty much their full rebuilds if any feature changes. Change-Id: If29bf78bd4fd70b37981e0826a577777fd255c89 Reviewed-on: https://gerrit.libreoffice.org/80776 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2019-10-14configure: remove sanitizer flags from default COMPILER_PLUGINS_CXXMichael Stahl
When COMPILER_PLUGINS_CXX is default initialised from $CXX, filter out sanitizer flags, because: a) linking fails with unresolved symbols currently b) typically the slowdown is unhelpful in a build c) if anybody wants a sanitized plugin they can set COMPILER_PLUGINS_CXX manually (init from CXX was added in ad5cbcf6ba0afdc1d8d7405c2641cce8de4a360b) Change-Id: I64dc48fae5f7a23f87b0eee0545add9a1ebd5672 Reviewed-on: https://gerrit.libreoffice.org/80655 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-10-12aarch64 callVirtualFunction needs to be compiled w/o -fstack-clash-protectionStephan Bergmann
At least when doing an aarch64 Flatpak build against org.freedesktop.Sdk//19.08, which uses GCC 9.2.0 and passes in `CXXFLAGS=-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection`, callVirtualMethod (in bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx) would decrement the stack pointer another 16 bytes after the stackargs = alloca(...); and before the asm block, so in the called virtual function, arguments read from the stack would read garbage (and CustomTarget_testtools/uno_test would fail with SIGSEGV at > #0 0x0000ffffb733eb48 in rtl::OUString::operator= (this=0xaaaaf9c1ac30, str=...) at /run/build/libreoffice/include/rtl/ustring.hxx:453 > #1 0x0000ffffb733a7bc in bridge_object::assign (rData=..., bBool=true, cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:99 > #2 0x0000ffffb733a87c in bridge_object::assign (rData=..., bBool=true, cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=..., rSequence=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:115 > #3 0x0000ffffb733ade4 in bridge_object::Test_Impl::setValues (this=0xaaaaf9c1abb0, bBool=1 '\001', cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=..., rSequence=..., rStruct=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:548 > #4 0x0000ffffb740bff4 in callVirtualFunction (function=281473755360772, gpr=0xffffd1ab1f28, fpr=0xffffd1ab1f68, stack=0xffffd1ab1d40, sp=8, ret=0xffffd1ab22c0) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx:63 > #5 0x0000ffffb740ca70 in (anonymous namespace)::call (proxy=0xaaaaf9c291c0, slot=..., returnType=0xaaaaf9c00770, count=17, parameters=0xaaaaf9c3a210, returnValue=0xffffd1ab22c0, arguments=0xffffd1ab2230, exception=0xffffd1ab2370) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:178 > #6 0x0000ffffb740d4c4 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch (pUnoI=0xaaaaf9c291c0, pMemberDescr=0xaaaaf9c55950, pReturn=0xffffd1ab22c0, pArgs=0xffffd1ab2230, ppException=0xffffd1ab2370) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:361 > #7 0x0000ffffb740720c in (anonymous namespace)::call (proxy=0xaaaaf9c549c0, description=..., returnType=0xaaaaf9c00770, count=17, parameters=0xaaaaf9c3a210, gpr=0xffffd1ab2510, fpr=0xffffd1ab2550, stack=0xffffd1ab2590, indirectRet=0xffffb7d24790) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:120 > #8 0x0000ffffb74079a0 in (anonymous namespace)::vtableCall (functionIndex=40, vtableOffset=0, gpr=0xffffd1ab2510, fpr=0xffffd1ab2550, stack=0xffffd1ab2590, indirectRet=0xffffb7d24790) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:291 > #9 0x0000ffffb7407b00 in (anonymous namespace)::vtableSlotCall (gpr0=187651311618536, gpr1=1, gpr2=64, gpr3=17, gpr4=4660, gpr5=65244, gpr6=305419896, gpr7=4275878552, fpr0=5.4321266044931319e-315, fpr1=3.1415926358999999, fpr2=0, fpr3=4.0039072046065485, fpr4=0, fpr5=4.003911019303815, fpr6=8.9589789687541617e+102, fpr7=-4.4588500238274385e-308) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:348 > #10 0x0000ffffb739e60c in bridge_test::performTest (xContext=..., xLBT=..., noCurrentContext=false) at /run/build/libreoffice/testtools/source/bridgetest/bridgetest.cxx:378 > #11 0x0000ffffb73a3d58 in bridge_test::TestBridgeImpl::run (this=0xaaaaf9c18550, rArgs=...) at /run/build/libreoffice/testtools/source/bridgetest/bridgetest.cxx:1162 > #12 0x0000aaaad292a3ec in sal_main () at /run/build/libreoffice/cpputools/source/unoexe/unoexe.cxx:509 > #13 0x0000aaaad29297a0 in main (argc=8, argv=0xffffd1ab31b8) at /run/build/libreoffice/cpputools/source/unoexe/unoexe.cxx:349 .) By experiment, I found the problematic thing to be -fstack-clash-protection, which can apparently be cancelled with a subsequent -fno-stack-clash-protection at least on that GCC 9.2.0. (And -f[no-]stack-clash-protection appears to only be available since GCC 8, and not at all for Clang, so check for it with HAVE_GCC_STACK_CLASH_PROTECTION.) Change-Id: If667fdf704b1ba20a04593b38d2d1f079280df41 Reviewed-on: https://gerrit.libreoffice.org/80701 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-12-fstack-protector-strong is long since availableStephan Bergmann
...on our baselines, since <https://gcc.gnu.org/git/ ?p=gcc.git;a=commitdiff;h=b156ec373ccf27f4fcce7972de5e043d35acea43> (GCC 4.9?) and <https://github.com/llvm/llvm-project/commit/ e0fc1a80cba8b91e3943f3287e7dcf68c6bb9b7f> "[stackprotector] Add command line option -fstack-protector-strong" (Clang 3.5?) Change-Id: I48237b2304a1ee273cc66f0bb458e890a5a2f21a Reviewed-on: https://gerrit.libreoffice.org/80700 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-10Set RTL_OS to "iOS" for iOSTor Lillqvist
We accidentally had left it as "MacOSX". Affects at least the "generator" metadata stored in documents. Change-Id: I72eeefdbe192409084f7ab7a24adbc39dcafb624
2019-10-09With Cygwin, AC_PATH_PROG needs Cygwin-style pathsStephan Bergmann
(And instead directly specifying CLANGDIR as a Cygwin-style path in my clang-cl build's autogen.input doesn't work, as compilerplugins/Makefile-clang.mk spells a dependency on $(CLANGDIR)/bin/clang$(CLANG_EXE_EXT) which Make on Windows requires to be a Windows-style path.) Change-Id: I20ee3a2dfff0a3db66e1388cd6fc01084a6fd812 Reviewed-on: https://gerrit.libreoffice.org/80471 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-09Bump the minimum iOS run-time version to 12.2Tor Lillqvist
Change-Id: I082a7d62e222e625d1d921bea39b45578118d225
2019-10-09Accept iOS SDK 13.1Tor Lillqvist
Change-Id: I02870b35f67dd9ca47061311186d74dfec823aa7
2019-10-08My Windows clang-cl build still doesn't use LO_CLANG_SHARED_PLUGINSStephan Bergmann
...so disable the new configure.ac checks introduced with ad5cbcf6ba0afdc1d8d7405c2641cce8de4a360b "try to autodetect flags needed to build Clang plugins" that are only relevant when using LO_CLANG_SHARED_PLUGINS and would fail miserably for my clang-cl build Change-Id: I58f7f1f4608f1a615175f0c0d0d98c03c442a36c Reviewed-on: https://gerrit.libreoffice.org/80477 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-08Clarify COMPILER_PLUGINS_CXX_LINKFLAGS vs. COMPILER_PLUGINS_LINKFLAGSStephan Bergmann
COMPILER_PLUGINS_CXX_LINKFLAGS was introduced with 39e7a72b3e328e6b3d87479d693b01315610457b "Support loplugin in clang-cl" to augment COMPILER_PLUGINS_CXX. Due to MSVC cl.exe command-line processing, certain linker-related arguments must come at the very end of the command line, so cannot be included in COMPILER_PLUGINS_CXX. COMPILER_PLUGINS_CXX_LINKFLAGS is specified in autogen.input (along with COMPILER_PLUGINS_CXX) and configure.ac merely passes it on to its use in compilerplugins/Makefile-clang.mk. ad5cbcf6ba0afdc1d8d7405c2641cce8de4a360b "try to autodetect flags needed to build Clang plugins" now needs a configure.ac-internal variable to store the output of `llvm-config --ldflags ...`, similarly to how COMPILER_PLUGINS_CXXFLAGS stores the output of `llvm-config --cxxflags`. It reused COMPILER_PLUGINS_CXX_LINKFLAGS for that, but that makes it hard for my clang-cl build to pass my specification of COMPILER_PLUGINS_CXX_LINKFLAGS from autogen.input to its use in compilerplugins/Makefile-clang.mk. So rename this new variable to COMPILER_PLUGINS_LINKFLAGS (matching COMPILER_PLUGINS_CXXFLAGS). Change-Id: I93b0b50ba94803041773757d9978222e2726f9b0 Reviewed-on: https://gerrit.libreoffice.org/80473 Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2019-10-08CXX is now always set before CXX_X64_BINARY on WindowsStephan Bergmann
...since ea3d4e806cbdde18173da92187329f1ac2177e14 "Fix CXX_BASE for clang-cl builds on Windows", as a side effect, moved the conditional CXX=$MSVC_CXX further up. This addresses the comment in the commit message of 463a79cbc16c1b4aba1775d7f8ae0324753c322c "CXX_X64_BINARY must be clang-cl not cl when building with clang-cl": "Ideally, the code would be reorganized so that CXX_X64_BINARY is only set after CXX has been set." Change-Id: Iaa011aeff88669ddd5d33fc5b1109abf02edff54 Reviewed-on: https://gerrit.libreoffice.org/80468 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-08Fix CXX_BASE for clang-cl builds on WindowsStephan Bergmann
...where the configure messages confusingly mentioned cl.exe instead of clang.exe (but the actual checks correctly used $CXX being clang) Change-Id: I9e0c6e1ab8ba64c45f752b413c3e6c22182506ac Reviewed-on: https://gerrit.libreoffice.org/80442 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-08update help text of --disable-guiAndras Timar
Change-Id: Idd01b11acee3683bbc3d81d0c2ccf8be6c4fbb69 Reviewed-on: https://gerrit.libreoffice.org/80428 Reviewed-by: Rene Engelhard <rene@debian.org> Tested-by: Rene Engelhard <rene@debian.org>
2019-10-08remove leftover debug output in configureLuboš Luňák
Change-Id: If2b1d7ca89f30544c4e8750119927701f9df5264
2019-10-07make the clang plugins configure check fasterLuboš Luňák
Use a header which is not so expensive to parse/compile. Change-Id: I4197fb16938b19c18fed541dbf94bf2c97a60e66 Reviewed-on: https://gerrit.libreoffice.org/80301 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-07try to autodetect flags needed to build Clang pluginsLuboš Luňák
Instead of having a lot of it hardcoded, which brings problems like: - Clang-to-be-10 has switched to -std=c++14, so our hardcoded c++11 makes the build fail - I cannot compile with my openSUSE-shipped clang, because it ships only libclang-cpp and not the other libClangSomething libs The possibility to explicitly set the necessary variables is still there. Change-Id: I58d401d4584fa064f1c1351a8a06ff4e29643063 Reviewed-on: https://gerrit.libreoffice.org/80300 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-06tdf#124456: Make Ant configure.ac check more robustDennis Schridde
Change-Id: Iee16dd23c7881756663e8b6a67e4391186a6e430 See-Also: https://bugs.gentoo.org/682156 Reviewed-on: https://gerrit.libreoffice.org/80233 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-02tdf#127711 - A runtime-switch for the MiniCrashDumpJuergen Funk
- in soffice.ini (sofficerc) the entry "CrashDumpEnable" default is "true" - when false then the Dump.ini and the dump-file are not written - when the switch --disable-crashdump is set, then the switch "CrashDumpEnable" set to "false" - when the entry "CrashDumpEnable" is missing, in this case is the default true, too - the checkbox under Options-General "Send crash reports to ..." is deactive and shows off (only view, not change the config) - when set the environment variable "CRASH_DUMP_ENABLE" to any char then the switch "CrashDumpEnable=false" are overrules with true and the Dump.ini and dump-file are write Change-Id: I34e7795640eb95d111e18b0ad46ec67b2c126b19 Reviewed-on: https://gerrit.libreoffice.org/79273 Tested-by: Jenkins Reviewed-by: Juergen Funk (CIB) <juergen.funk_ml@cib.de>
2019-10-01CXX_X64_BINARY must be clang-cl not cl when building with clang-clStephan Bergmann
...to avoid failures like > [build CXX] shell/source/win32/spsupp/registrar_x64.cxx > cl : Command line error D8021 : invalid numeric argument '/Wendif-labels' after 58ef8c188b6bb2ed307f5e825cc7e475c33d0c33 "Make spsupp*.dll usable on 64- bit Windows". This is a bit of a hack, relying on CXX being passed in via autogen.input in my clang-cl build. Ideally, the code would be reorganized so that CXX_X64_BINARY is only set after CXX has been set. Change-Id: Ia2c823ad6b917218858ea541cc6a65fa423e3a09 Reviewed-on: https://gerrit.libreoffice.org/79959 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-01redmine#2555 replace Help online Google searchOlivier Hallot
This is the core/ part of the patch. Add xapian-omega search to online Help. The patch replaces Google custom search with xapian-omega search. A new build key is introduced. --with-omindex=server : Localizes and adds the xapian result page, adds the xapian form to each Help page. --with-omindex=noxap : do not localize the result template and do not add a form in the Help page. --with-omindex will force Online Help build. Default is noxap NOTES: - searches returns resuls only on localized Help pages, avoiding same resulis in many languages. -xapian-omega databases must be built in server TODO: - Tweak the xapian-omega result page CSS and markup. Change-Id: I5e3fe4191a3b054e3b6403f7cb5640953d92ba42 Reviewed-on: https://gerrit.libreoffice.org/79368 Tested-by: Jenkins Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
2019-09-30drop gtk2 supportCaolán McNamara
Change-Id: Ie838cabfecfef7e3225c1555536d5c9cf3b43f15 Reviewed-on: https://gerrit.libreoffice.org/77405 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-09-27Revert "tdf#121925 test for URLClassPath.ClassPathURLCheck"Stephan Bergmann
This reverts commit 905c107cde4a0a7059b1e11b5f23a0a59188cb0c. Conflicts: configure.ac As discussed at <https://bugs.documentfoundation.org/show_bug.cgi?id=121925#c12> "Fix Java Jar dependency classpath to pass the ClassPathURLCheck": "At least with java-latest-openjdk-headless-13.0.0.33-1.rolling.fc31.x86_64, the testurlcheck program in configure.ac reports 'false', but (when you convert the corresponding AC_MSG_ERROR into a AC_MSG_RESULT to not make configure fail) a full `make check screenshot` works fine for me." Change-Id: I205bada5e8eeede7b33cdbc3f87a629edb8b9872 Reviewed-on: https://gerrit.libreoffice.org/79687 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-25constinit, here we comeStephan Bergmann
Following up on b13421011d9377676e1adc282634991d5064a866 "better data structures for some static const vars": * Make the o3tl::sorted_vector ctor taking an initializer_list constexpr. <https://wg21.link/P0202R3> "Add Constexpr Modifiers to Functions in <algorithm> and <utility> Headers", which will be in C++2a and is already implemented by recent libc++ and libstdc++ according to <https://en.cppreference.com/w/cpp/compiler_support #C.2B.2B2a_library_features>, makes std::sort constexpr but explicitly keeps std::stable_sort non-constexpr. ("Algorithms stable_partition, inplace_merge and stable_sort allocate memory, construct variables using placement new, use unique_ptr and do other things not acceptable in constexpr expressions. Making those algorithms constexpr seems to be a hard task that would require a lot of intrinsics. Those algorithms are not marked with constexpr in this wording.") But keep o3tl::sorted_vector::Resort (which was introduced in c59355e936446fe55960209e543b072acb6b2170 "fdo#58793: re-implement SwpHintsArray::Resort()") using std::stable_sort instead of std::sort, in case that is relevant for its pre-exisiting uses. * <https://wg21.link/P1004R2> "Making std::vector constexpr", which was voted into C++2a according to <https://wg21.link/n4829> "Editors' Report -- Programming Languages -- C++", will make the relevant parts of std::vector constexpr. But none of libc++, libstdc++, and MSVC implement that as of now. * Introduce HAVE_CPP_CONSTINIT_SORTED_VECTOR to hide the constinit behind for now for the one case from b13421011d9377676e1adc282634991d5064a866 "better data structures for some static const vars" that can clearly be constinit once constexpr std::vector is supported by compilers. The other three cases (s_aContainerDocumentCommands in chart2/source/controller/main/CommandDispatchContainer.cxx, aMetricCompatibleMap in vcl/source/font/PhysicalFontCollection.cxx, and aBlacklist in writerfilter/source/dmapper/PropertyMap.cxx) would each need a constexpr OUString first. (Technically, the constinit would not even be needed, but it nicely documents our intent that this will actually be initialized at compile-time once compilers support that.) Change-Id: Ibeb138f120528be3a7a09b3912143bf795fbab29 Reviewed-on: https://gerrit.libreoffice.org/79556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-23Let's not bother looking for quite old iOS SDKsTor Lillqvist
Change-Id: I449d5fe425d741ca3b4a3be84e7e2bc015e90e32
2019-09-23iOS SDK 13.0 is the current versionTor Lillqvist
Change-Id: Icd8455ce122530e69f01b8345cbd02925305429f
2019-09-23This if branch is for macOS, not iOSTor Lillqvist
Change-Id: I4a502d4247bf86fd2bc5734a64e600ae0e214f21
2019-09-23android: add support for 64bit buildChristian Lohmaier
Change-Id: Id8aae84308f6128351ae2f93c8fbc8941a0c7fc6 Reviewed-on: https://gerrit.libreoffice.org/79085 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2019-09-20Remove legacy NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY supportStephan Bergmann
...for ASan/UBSan builds using Clang older than current trunk twoards Clang 9, as announced at <https://lists.freedesktop.org/archives/libreoffice/2019-May/082654.html> "Re: [Libreoffice-commits] core.git: The -fvisibility-ms-compat hack is no longer needed for UBSan on Linux...". (And drop the no longer needed solenv/sanitizers/asan-suppressions, which people might still reference from their ASAN_OPTIONS.) Change-Id: Iedc0c5955366d2cbe7dc847990e2b1576750e85b Reviewed-on: https://gerrit.libreoffice.org/72493 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-07tdf#125368, Make KJ SVG icons available in the apprizmut
Change-Id: I023cd3ce765d0e620d22c95b7091efc1ede8ce9b Reviewed-on: https://gerrit.libreoffice.org/78741 Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org> Tested-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>
2019-09-06Fixing '....'Andrea Gelmini
Change-Id: Icf2a34500acc18b28f113c85366bf24edc6d20b9 Reviewed-on: https://gerrit.libreoffice.org/78695 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-09-02add -latomic configure check...Rene Engelhard
...in preparation for <https://gerrit.libreoffice.org/#/c/78380/> "Add -latomic to the end of Linux C++ linker command lines" (copied from https://github.com/zelcash/zelcash/blob/master/build-aux/m4/l_atomic.m4) Change-Id: I8879a72d730cc08a72c2d8b132ff9f5d2efe7b9f Reviewed-on: https://gerrit.libreoffice.org/78336 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-02configure.ac: Fix '--enable-kde5' compatibility switchMichael Weghorn
The 'kde5' VCL plugin was renamed to 'kf5' in commit d3c6ac6d0f23df56644008ccb6aa2c8fa37ab1b5 ("tdf#125922 rename kde5 to kf5 + plasma5). Fix the (temporary) compatibility switch, so that '--enable-kde5' actually enables the build of the 'kf5' VCL plugin and doesn't just set 'test_kf5' to 'yes' once again... Change-Id: I7871b5fc1dc36758a3e3d558da44ae24fd47de41 Reviewed-on: https://gerrit.libreoffice.org/78393 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2019-09-01Fix '..'Andrea Gelmini
To complete this: https://gerrit.libreoffice.org/#/c/78312/ This is a massive replace for lines ending with ".." instead of "..." It passed "make check" on Linux. Change-Id: I07fa7b2e30ba9ea17a1f9a5e21c57216ba958efe Reviewed-on: https://gerrit.libreoffice.org/78356 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2019-08-15Switch mdds to 1.5.0 and liborcus to 0.15.0.Kohei Yoshida
Change-Id: Ibff9a5e0f0771e4cf12b4dc3985661a01195e265 Reviewed-on: https://gerrit.libreoffice.org/77482 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2019-08-13Remove redundant Java >= 8 checkStephan Bergmann
...after aafc10c9edb61e13ac557c7e43c8d4a31dce4f37 "Bump Java baseline to Java 8" Change-Id: Id5b2ad33dd89563028849b613676fba24581b2ec Reviewed-on: https://gerrit.libreoffice.org/77388 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-13configure: don't enable export validation if there are no schemasMichael Stahl
Schemas are excluded from tarballs since commit 34dced99c33a97dab86c4538fa267ad4ad4fb41f because of the license. Change-Id: I6540926d9ebb390d7956bbd1df3bb915adebb64b Reviewed-on: https://gerrit.libreoffice.org/77383 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-08-12improve error message for gtk configureNoel Grandin
Change-Id: I0b46302bbb15777992d59597109fe9ebd76a525e Reviewed-on: https://gerrit.libreoffice.org/77346 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-08android: support NDK 19 and above (20 as of this commit)Christian Lohmaier
support for targeting API 14 and 15 was removed in NDK 18, so set minimum version to 16 mips support was removed in NDK 17 Clang now takes care about correct linking with libc++ shared or static, so don't manually specify them anymore. Same with __ANDROID_API_LEVEL__ define and the sysroot / isystem handling, that is all covered by a single -target <triple><version> simplifying things quite a bit. also align ownloud sdk values with main build.gradle Change-Id: Ib3ae4484e52214677e826270b731ecf7c5c15445 Reviewed-on: https://gerrit.libreoffice.org/77104 Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2019-08-06Introduce explicit --enable-introspectionStephan Bergmann
4b4c7e76e6c2ea0d47a42a5107352d3ad7341fbf "Only build LOKDocView-0.1.gir when necessary" had erroneously assumed that LOKDocView-0.1.{gir,typelib} need to be built when PKGFORMAT contains "deb" or "rpm". But instead, they need to be built only for some 3rd-party Linux distro builds, never for TDF builds. Make that explicit with a new --enable-introspection, which those 3rd-party Linux distros will now have to specify (probably along with other fixes to where they pick up those LOKDocView-0.1.{gir,typelib} files after 634844354ee6ed884128086a80c3ee32c889d8c9 "sysui: fix rpm errors in freedesktop-menus (4.14.1)" had moved them around). That way, builds that broke after 634844354ee6ed884128086a80c3ee32c889d8c9 "sysui: fix rpm errors in freedesktop-menus (4.14.1)" (like my ASan+UBSan one that 4b4c7e76e6c2ea0d47a42a5107352d3ad7341fbf "Only build LOKDocView-0.1.gir when necessary" had tried to fix) can be fixed with an (implicit) --disable-introspection. This commit contains a revert of 4b4c7e76e6c2ea0d47a42a5107352d3ad7341fbf "Only build LOKDocView-0.1.gir when necessary", which it supersedes. Change-Id: Idb618e3353da7d68a2e552b0f290775c02327733 Reviewed-on: https://gerrit.libreoffice.org/76997 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-02build fails with libxmlsec version 1.2.27Lionel Elie Mamane
Due to indirect inclusion of C++ headers in scope of an 'extern "C"'. Possibly it works with version 1.2.24 to 1.2.26. Change-Id: I12bd43b51b1cf829bfe91d4ab1eb5470b86ec18e Reviewed-on: https://gerrit.libreoffice.org/75349 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-07-31sysui: fix rpm errors in freedesktop-menus (4.14.1)Michael Stahl
RPM build errors: Explicit %attr() mode not applicable to symlink: /workdir/CustomTarget/sysui/rpm/libreofficedev/freedesktop/usr/bin/libreofficedev6.1 Installed (but unpackaged) file(s) found: /usr/local/lib/girepository-1.0/LOKDocView-0.1.typelib /usr/share/gir-1.0/LOKDocView-0.1.gir The LOKDocView problem turned out to be the result of the first incremental build after adding --with-package-format, and previously it was avoided with a if in configure; moving the commands out of create_tree.sh should be more obvious and reliable though. Change-Id: I69c1566e26eeaa1d8bf88a3650a78da6ddfb5a3b Reviewed-on: https://gerrit.libreoffice.org/76596 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-07-26Bump Java baseline to Java 8Stephan Bergmann
...as discussed at <https://lists.freedesktop.org/archives/libreoffice/2019-July/083193.html> "Minutes of ESC call: 2019-07-25". 3d27b2fa9c5a03f78e5145377402f8a88e3da1be "tdf#124503: Support JRE installations with unknown java.vendor property" had added support for JREs with unknown vendor strings without checking that those JREs have a matching version (Java 6 back then, Java 8 now). That check has still not be implemented, assuming that Java 8 is old enough in practice so that any such JRE encountered in the wild will at least be Java 8 anyway. Change-Id: I0205a34955368067c698bcabd24de84205a382bd Reviewed-on: https://gerrit.libreoffice.org/76365 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-24Accept also iOS SDK 12.4Tor Lillqvist
Change-Id: I7bf7a428d53b7a1a4e0675414c4532f1f5b763a9
2019-07-24Clarify a warningTor Lillqvist
Change-Id: I485efe5fae00c8ddfb250f5f794d789f91816d6b
2019-07-22Explicitly disable qt5 on AndroidJan-Marek Glogowski
Regression from commit d3c6ac6d0f23 ("tdf#125922 rename kde5 to kf5 + plasma5"). Change-Id: I47f2a3977094acc0c7b4ae0af28c3774eba2daca Reviewed-on: https://gerrit.libreoffice.org/76078 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-07-21tdf#125922 rename kde5 to kf5 + plasma5Jan-Marek Glogowski
Just as the gtk3 plugin isn't named GNOME, rename kde5 to kf5, as it is based on the KDE frameworks 5 libraries. This also includes: * a convenience alias to load the kf5 VCL plugin in case someone requests the kde5 plugin. * keep convenience kde5 configure switch, but warn about it * rename detected desktop from kde5 to plasma5 Change-Id: I6764a05b81a5edbf284484c234fee2649aacf735 Reviewed-on: https://gerrit.libreoffice.org/75313 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-07-14tdf#120047 use new opens___.ttf version 102.11Andras Timar
Change-Id: Iad48c663708dc9cda00d2a8534981f34c1c6f9d0 Reviewed-on: https://gerrit.libreoffice.org/75577 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2019-07-10We don't support building with Windows SDK 7.1AMike Kaganski
... it's already impossible with 6.2; and was only needed prior to 6.0, where Windows XP support was needed. Change-Id: Ia462f0b6566ae35bd68545d2d34d2987ee7907b9 Reviewed-on: https://gerrit.libreoffice.org/75334 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-07-10Fix typoAndrea Gelmini
Change-Id: Ic6d27877d757ff1a379e278053630dd5f3d14807 Reviewed-on: https://gerrit.libreoffice.org/75307 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>