summaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2020-01-09python3: bundle libffi for GNU/Linux buildsMichael Stahl
CPython commit f40d4ddff3c800b3c956a5e8820aabe3aa87cddd "Closes #27979: Remove bundled copy of libffi" causes a bit of a problem because it turns out that libffi isn't all that stable; there's libffi.so.5 on CentOS 6, libffi.so.6 on CentOS 7 and libffi.so.7 on lo_daily_update_gandalf tinderbox. So we have to bundle it in LO; it's only used on GNU/Linux currently. CPython commit 32119e10b792ad7ee4e5f951a2d89ddbaf111cc5 "bpo-35947: Update Windows to the current version of libffi (GH-11797)" also removes the libffi for MSVC, so in a future python upgrade we will have to build libffi for MSVC too. The libffi fork for MacOSX is still in CPython git master. (regression from b10be5d48433076f0b7238d818020f708553e114) Change-Id: Ibc20cf8cd3614cf9941b6970662bd930496776b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86493 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-08python3: upgrade to release 3.7.6Michael Stahl
* external/python3/python-3.3.3-aix.patch.1: most of it doesn't apply and AIX port isn't maintained anyway so remove it for now * external/python3/ubsan.patch.0: apparently one of the files was removed * 0001-3.6-bpo-17239-Disable-external-entities-in-SAX-parse.patch.1: fixed upstream * python3-osx-avoid-new-10.13.patch.1: replace with simply passing ac_cv_func_utimensat=no to configure * external/python3/python-3.5.4-ssl.patch.1: project files to build OpenSSL removed upstream * There have been changes to how python locates OpenSSL; new variables OPENSSL_INCLUDES etc; it turns out that you have to pass one directory to --with-openssl, as the variables cannot be passed * libuuid.so.1 is a new dependency of the _uuid module * libffi.so.6 is a new dependency of the _ctypes module (the bundled copy of libffi for non-Darwin platforms was removed) * python-3.3.0-pythreadstate.patch.1: the PyThreadState functions have been changed such that CppunitTest_services asserts when there is a PyThreadAttach on top of PyThreadDetach on top of PyThreadAttach, i.e., 2 PyThreadState per thread (PyGILState_Check() fails). Instead of patching in additional workarounds, change PyThreadAttach so that it re-uses an existing PyThreadState if one exists for the thread. Change-Id: I24c19d79b43a30709261fd9db66312b2e3872fd9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84765 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-03Use only the 'MacOSXSpell' component on iOS, not the 'spell' oneTor Lillqvist
Using only the system spell checker (through MacOSXSpell) is what we have been doing anyway. Do not build the hunspell or mythes externals for iOS. Do not build the lnth or spell components for iOS. Change-Id: I2e2abc268d7719e540072e5daff3f7960e04ed27 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86172 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86174 Tested-by: Jenkins
2019-12-29Fix order of CLANGTOOLLIBS archivesStephan Bergmann
Building compilerplugins against recent Clang 10 trunk started to fail with > [GEN] compilerplugins/clang/sharedvisitor/analyzer [...] > /usr/bin/ld: /home/sbergman/llvm/inst/lib/libclangFrontend.a(CompilerInvocation.cpp.o): in function `getOptimizationLevel(llvm::opt::ArgList&, clang::InputKind, clang::DiagnosticsEngine&) [clone .isra.0]': > /home/sbergman/github.com/llvm/llvm-project/clang/include/clang/Driver/OptionUtils.h:40: undefined reference to `clang::getLastArgIntValue(llvm::opt::ArgList const&, llvm::opt::OptSpecifier, int, clang::DiagnosticsEngine*, unsigned int)' [...] Change-Id: I3b74d71bd2488ebd5cc7e3a88d4eb0451268141c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85934 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-18Fix typos concerning the __cxa_exception checkStephan Bergmann
...introduced with 069506bcb0ee4005b01c22095ed427b96b553c98 "Use config_cxxabi.h to check for __cxa_eh_globals, __cxa_exception", but which appear to have been harmless as (a) the checked-for __cxxabiv1::__cxa_exceptions never existed in cxxabi.h, and (b) lack of __cxxabiv1::__cxa_exception in cxxabi.h happened to conincide with !HAVE_CXXABI_H_CXA_EH_GLOBALS Change-Id: I13f8a2b3cf0f03f2bc96cf053d2b571860055978 Reviewed-on: https://gerrit.libreoffice.org/85373 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-17Tweak configure to allow Windows builds using VC++ Build ToolsStepas Toliautas
Since Visual Studio 2017 Microsoft offers Build Tools installer package which comes with MSVC++ compiler and can include most toolchains and libraries, but does not require Visual Studio IDE installation. This patch asks vswhere.exe to use path to Build Tools as compiler path (in case Visual Studio path is not found) and lowers 'devenv' detection error to warning with an explanation. Identical build is produced in both cases, and even IDE integration (creation of sln/vsproj) works as usual. Change-Id: I6176d10cc6ea2091c353eb40d13913d8adb8f85d Reviewed-on: https://gerrit.libreoffice.org/85245 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-12-17Remove dated check for jre sub-dir in JDKStephan Bergmann
Since Java 9, a JDK installation no longer necessarily has a jre sub-dir, see <https://docs.oracle.com/javase/9/install/ installed-directory-structure-jdk-and-jre.htm> vs. <https://docs.oracle.com/javase/8/docs/technotes/tools/windows/jdkfiles.html>. The check for a jre sub-dir had been there ever since 157d22babb277a9e7bc750a74737cd60e84dfee8 "INTEGRATION: CWS rodarvus01", but the code that determines a working JAVA_HOME has been improved a lot since then. Given that the current check can be misleading (see <https://lists.freedesktop.org/archives/libreoffice/2019-December/084005.html> "Re: what jdk for build?"), better remove it completely and hope that the code determining a working JAVA_HOME is good enough by now. Change-Id: Ib1da3c00b8a3f1e54d5204e6ecd43b4c4441c827 Reviewed-on: https://gerrit.libreoffice.org/85257 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-14Rename HAVE_GCC_BUG_87150 to HAVE_P1155R3Stephan Bergmann
...to match the new reality (see comment in config_host/config_global.h.in) Change-Id: I5450e520d8b82584e3fd71d7e42a6840993b5ddb Reviewed-on: https://gerrit.libreoffice.org/85142 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-12Enable -Wdeprecated-copy-dtor where availableStephan Bergmann
We already get -Wdeprecated-copy (warning about implicitly defined copy functions that will in the future be deleted because other user-provided copy functions exist) automatically through -Wextra, where available. -Wdeprecated-copy-dtor (warning about implicitly defined copy functions that will in the future be deleted because of a user-provided dtor) is split off into its own warning excluded from -Wextra for somewhat unclear reasons, see the discussion at <https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=88136> "-Wdeprecated-copy is draconian and shouldn't be in -Wall". But -Wdeprecated-copy-dtor has been useful in finding issues (esp. the Clang 10 trunk version, which, unlike the GCC 9 version, also finds copy functions that are implicitly defined because they are used from template instantiations), see 3e59716375a240576fd6d8759b32b4319506ed70 "Prevent BroadcastRecalcOnRefMoveHandler copies" and 4f98cd0f9ce9c2a331a5d34b3ef9d18f9bb6b235 "ScShapeChild has broken copy functions". We need to disable -Wdeprecated-copy-dtor in files included from external/boost, and in two compilerplugin/clang/test/ files. Change-Id: I74b159c3a046e23661473ddbfe53c92c4136a9db Reviewed-on: https://gerrit.libreoffice.org/85073 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-07Adapt o3tl::span to P1872R0Stephan Bergmann
..."span should have size_type, not index_type" (<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1872r0.pdf>), as implemented by libc++ since <https://github.com/llvm/llvm-project/commit/ 1466335cf4b2854a0be1defcf279fe50772bad6f> "[libc++][P1872] span should have size_type, not index_type." All uses of index_type had been added to mitigate the previous std::span change from signed (ptrdiff_t) to unsigned (size_t) index_type, see 6ef8420fdbf8dff16de13147c5ab833bc5e01121 "Adapt o3tl::span to updated C++2a std::span". There is no easy solution to transparently support all three std::span variants currently out there (signed index_type, unsigned index_type, unsigned size_type), without causing compilation failures due to CPPUNIT_ASSERT_EQUAL with arguments of different types, or compiler warnings about mixed signed/unsigned comparisons. So rule out the oldest std::span variant (signed index_type) in configure.ac (so that o3tl::span will use its own hand-rolled code in that case) and simplify the uses of index_type to std::size_t (as had already been mentioned in 6ef8420fdbf8dff16de13147c5ab833bc5e01121). Change-Id: I6ddf424ffb7941da3f69ad66fd29ecd35f09afae Reviewed-on: https://gerrit.libreoffice.org/84652 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-06Honor BISON passed into configureStephan Bergmann
...and require new-enough Bison for --enable-compiler-plugins to not generate bogus loplugin:external warnings in Bison boilerplate code. (As happend for me on macOS where /usr/bin/bison is version 2.3. Not sure which versions exactly are too old, but at least 3.4.1 is known good. If other versions newer than 2.3 turn out to be problematic too, the configure.ac check will need to be adapted.) No idea why there need to be three places across solenv/gbuild/ that set gb_YACC (to the same bison in each case), but leave that to be cleaned up later. Change-Id: I01d8219726f8df7895631b817866207327367759 Reviewed-on: https://gerrit.libreoffice.org/84650 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-06Qt5 fix missing XCB_ICCCM_WM_HINT_WINDOW_GROUPJan-Marek Glogowski
This is the application level equivalent of the Qt5 fix for bug QTBUG-46626 / commit 0de4b32 ("xcb: fix issue with dialogs hidden by other windows"), which was broken since Qt 5.4 and is just fixed since Qt 5.12. It is needed for some window managers, which don't know about the WM_CLIENT_LEADER property. Both settings are the same, but just the latter is set by older Qt5 releases. This probably isn't a real problem, as GNOME or XFCE would use the gtk VCL plugin, but since I already wrote the code when debugging tdf#129071, there is also no reason to drop it (except: more code, more bugs...). This fix is optional and needs development headers for xcb-icccm, which can actually be compiled into Qt5. If missing configure will just print a warning, since it's a runtime requirement and we explicitly drop the linked Qt version symbol, so the potential build Qt version won't matter. Change-Id: Ifc5a8f8a40ee13779a911efb53e8b8b868614d0b Reviewed-on: https://gerrit.libreoffice.org/84299 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-12-03split instrinsics CXXFLAGS per each instruction setLuboš Luňák
The common usage pattern should be having one source file per each instruction set and then one source file compiled with neutral flags that dispatches to the relevant code based on runtime checks. Which means that there can't be any one "correct" flag, otherwise all files would get compiled e.g. with SSE4.2 but then CPUs capable only of SSE2 would crash running that code. Change-Id: I362bf66f672dae4588a48effe3bcd30c34ea75b3 Reviewed-on: https://gerrit.libreoffice.org/84227 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-12-02android: Fix location of the built freetype library.Jan Holesovsky
Otherwise it is not found when the the fontconfig's ./configure is running, which leads to linking failure during the fontconfig's ./configure time, which leads to an undefined HAVE_FT_GET_NEXT_CHAR which leads to not using the actual FT_Get_Next_Char, but instead some dummy code that leads to an infinite loop on the app startup; huh. Change-Id: I40b7a403fbe75582bb98f15f1afe7a4050fd13aa Reviewed-on: https://gerrit.libreoffice.org/83922 Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com> (cherry picked from commit 94eb59078731b2e4093d983bc618d051f4e31740) Reviewed-on: https://gerrit.libreoffice.org/84190 Tested-by: Jenkins
2019-11-27android: Introduce --enable-android-lok configure switch to fix RGB vs. BGR.Jan Holesovsky
This indicates that the build targets the Online-based Android app, for which we need to avoid various tweaks that are needed for the 'old' Android app present in the android/ subdir of core.git. In particular, the switch used in this patch fixes a RGBA vs. BGRA confusion that caused yellow <-> cyan switch in the Online-based Android app. Change-Id: I5f394868f51ce87013677834cfafb967b9bb333e Reviewed-on: https://gerrit.libreoffice.org/83342 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Jan Holesovsky <kendy@collabora.com> (cherry picked from commit 49002a143a4534df5f6139e07fefd06174621c59) Reviewed-on: https://gerrit.libreoffice.org/83718 Tested-by: Jenkins
2019-11-27build Skia only on selected platformsLuboš Luňák
Feel free to adjust your platform as necessary. Change-Id: I3003a643c39b6afeb3102f97280f20534b9c7f77
2019-11-27build skia by defaultLuboš Luňák
Change-Id: Ia7d9c95b2e1e78481755f40d817c6f16a5d2b4ed
2019-11-27use the same config file for skia build and using itLuboš Luňák
So that the setup is consistent. Change-Id: Ia113c7bf79036e3ec7585263ed70da68e461fbac
2019-11-27initial build of the Skia libraryLuboš Luňák
Not quite complete yet, missing e.g. Vulkan sources, and the setup is not completely correct either. Change-Id: I2283bf12f0d226ff8a34554deae5a7bd69045971
2019-11-19python3: upgrade to release 3.5.9Michael Stahl
Fixes CVE-2019-9948 CVE-2019-9740 CVE-2019-10160 CVE-2019-16056 and expat CVE-2019-15903. python-3.3.5-pyexpat-symbols.patch.1 fails to apply, and it's a mystery why --with-system-expat is used everywhere but on MacOSX, where 292af048ace2d4b455b2da3a22c784cb05db1d09 disabled it for no obvious reason, so try to remove the special case and get rid of the patch. Change-Id: I5ba4532eb6e7c2fb90daba95d132dcc7c9013d96 Reviewed-on: https://gerrit.libreoffice.org/83117 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-11-14--with-windows-sdk: correct parameter is 10.0, not 10Mike Kaganski
Change-Id: I337857ccc5fe6701f6fd11449afaf7ed2b9af6e1 Reviewed-on: https://gerrit.libreoffice.org/82645 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-11-13bump product version to 6.5.0.0.alpha0+Xisco Fauli
Change-Id: If79dfdeb712956e499ff3d6827046b3b33d6aace
2019-11-04find Clang headers also if it's Clang built from sourceLuboš Luňák
Change-Id: I2253bdce982028277b30d7bf911201675be45ca4 Reviewed-on: https://gerrit.libreoffice.org/81919 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-11-01Accept iOS SDK 13.2Tor Lillqvist
Change-Id: I5d42a60a257661f39d1c9af6299ca3278f783d2b Reviewed-on: https://gerrit.libreoffice.org/81870 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2019-10-30fix vcldemo lookup of iconsLuboš Luňák
Icon themes are in [srcdir]/icon-themes, which is not necessarily the same as $PWD/icon-themes. Change-Id: Id2c5037afcbea4ea7dd511a9e10e19e05fa52a5a Reviewed-on: https://gerrit.libreoffice.org/81701 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-30Upgrade to ICU 65.1Eike Rathke
sberg says: On Windows, implicit --enable-extras first causes a build breaker in workdir/UnpackedTarball/icu/source/extras/scrptrun when linking, because Windows link.exe doesn't understand -o. But even with a patch > --- source/extra/scrptrun/Makefile.in > +++ source/extra/scrptrun/Makefile.in > @@ -74,7 +74,7 @@ > && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status > > $(TARGET) : $(OBJECTS) > - $(LINK.cc) -o $@ $^ $(LIBS) > + $(LINK.cc) $(OUTOPT)$@ $^ $(LIBS) > $(POST_BUILD_STEP) > > invoke: linking would still fail with a missing ../../lib/icuucdd.lib, which is apparently expanded from $(LIBS) there, but I have no idea where it should be built but isn't. Lets hope that --disable-extras is sufficient for our needs. Change-Id: I6d0117b230caa41abf488fcd069028e3474700f8 Reviewed-on: https://gerrit.libreoffice.org/81632 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-28Upgrade to ICU 64.2Eike Rathke
As an interim step to upgrade to ICU 65.1 Adds new scripts and Unicode blocks from Unicode 12. Change-Id: Idc4a6b29ffb04bcb424522fcbd29a8db0428c056 Reviewed-on: https://gerrit.libreoffice.org/81611 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2019-10-24android: Allow specification of the API level.Jan Holesovsky
Change-Id: Icf33e2703f42a7866ce895437cf5f276066eeebe Reviewed-on: https://gerrit.libreoffice.org/81227 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Jan Holesovsky <kendy@collabora.com> (cherry picked from commit 59eee888bf7174114e5749855d95e8ff7dd15013) Reviewed-on: https://gerrit.libreoffice.org/81327 Tested-by: Jenkins
2019-10-24android: Allow using SDK and NDK directly from the Android Studio.Jan Holesovsky
Just specify: --with-android-ndk=$HOME/Android/Sdk/ndk-bundle --with-android-sdk=$HOME/Android/Sdk in your autogen.input, install the appropriate components via Android Studio and you are done. Change-Id: Ic99790b781b9017eb4e642380e230d6f7b49e9b7 Reviewed-on: https://gerrit.libreoffice.org/81228 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Jan Holesovsky <kendy@collabora.com> (cherry picked from commit 246f1b5b4485b7db9f9584e4b3b819c87e331c0e) Reviewed-on: https://gerrit.libreoffice.org/81328 Tested-by: Jenkins
2019-10-21We do not need a C++ GNU dialectStephan Bergmann
1cf7ab61a71d4b7295942ff5c855896e60c15081 "use -std=gnu++0x rather than -std=c++0x" appears to have started this, but the only rationale it gives is that it keeps things in sync with GCC's default behavior when no -std= is given. But it apparently works fine to build with a -std=c++... standard dialect. This allows to get rid of the check introduced with 50cd28e5728b6a64c1e605567540739ea6ef42ca "Ensure configuration that defines math_errhandling in <cmath>". (It kept bothering me to say "I observe this-and-this with -std=c++2a" when what configure.ac made me actually use was -std=gnu++2a. And truthfully saying "-std=gnu++2a" would have been a distraction, as what is relevant for such an observation is most likely the "2a" and not the "gnu" part.) Change-Id: I7c213a702ffb7df6f4c2c4a421008e30e2712a51 Reviewed-on: https://gerrit.libreoffice.org/81176 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-18tdf#128189: fix couple issues in configure.acJulien Nabet
Patch from David L. Craig License statement in lo-dev forum 2019/10/18 Change-Id: I772807b66e096c0abba1cf464aaced432209451f Reviewed-on: https://gerrit.libreoffice.org/81005 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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>
generated by cgit (git 2.34.1) at 2025-01-30 18:06:52 +0000