summaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2020-01-29Fix typoAndrea Gelmini
Change-Id: I27f2c02ff3d4ab277219428be99b1219f1d6e94e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87667 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2020-01-28HAVE_GCC_ATTRIBUTE_WARN_UNUSED should always be true now for Clang/GCCStephan Bergmann
...but for safety, leave the configure.ac check in for some longer. Change-Id: I90cba5812492ba85d7723ff71aba75b7721b9622 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87621 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-28Remove obsolete Clang <= 3.8 __float128 checkStephan Bergmann
According to README.md, for Linux the baseline is Clang 5.0.2, and for macOS and iOS (should this libstdc++ __float128 stuff be relevant for either of them at all) the baseline is Xcode 9.3 which maps to ca. LLVM 5.0.2 according to <https://en.wikipedia.org/wiki/Xcode# Xcode_7.0_-_11.x_(since_Free_On-Device_Development)>. Change-Id: Ibd916cff795998bc63398695be63481cfd02abcd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87618 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-24Fix --with-visual-studio help output: 2019 is supportedMike Kaganski
Change-Id: Id9c3987a5fdaca8722d7ad8cabe1d1ef523b598e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87302 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-01-23next major version will be 7.0Christian Lohmaier
Change-Id: If618bf789370ee462b562cc5977b41802fbe47b5
2020-01-20tdf#128849: Added svg version of the breeze dark icon set.Luca Carlon
Change-Id: I045d8acd5b42473b220f7c9bb96e2a87d6141727 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86590 Tested-by: Jenkins Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id> Tested-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>
2020-01-18use -Wl,-dead_strip on Mac, its linker doesn't know -Wl,--gc-sectionsLuboš Luňák
Change-Id: Ic69d0030a46fe4753cc75da58bb2c15cf009b135 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87023 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-18support Clang's -fmodules-codegen/debuginfo options for PCH buildingLuboš Luňák
These (starting with my patches for Clang-to-be-10) allowing emitting debuginfo and functions into a dedicated object file, so that all the normal compilations using the PCH can skip those, thus saving the time. The debuginfo option seems to always be worth it. The codegen option is more tricky, it doesn't seem to be worth it for optimized builds (optimizing all the functions in that one object file costs too much). This requires also using --Wl,--gc-sections . The reason is that the object file contains all template instances instantiated from the PCH, so that they can be shared, but the template instance may come from another library or use a private symbol from that library. For example the std::unique_ptr<ScInterpreterContext> in ScInterpreterContextPool in the header refers to ScInterpreterContext dtor. But even though both these classes are private, the header gets used also by scfilt, because there it is included by document.hxx because of a private ScDocument data member. So even though nothing in scfilt uses ScInterpreterContext, the PCH object file will refer to it. Fortunately that template instance itself is not used by scfilt, so --gc-sections will remove it. Change-Id: I2a06ebcc4dd4175424b3a72ab3ebcaf2ac3ee295 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87011 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-18add support for Clang's -building-pch-with-objLuboš Luňák
This marks the PCH as having an accompanying object file, and this object file needs to be also built, but this allows the compiler to skip generating stuff that'd be shared by all the objects using the PCH. Currently it doesn't make much of a difference, few symbols if any, but template instantiations could be shared this way, as soon as Clang gets the necessary support (my WIP patch). Change-Id: Ib1b86338d85a47b48979558435253dc2672a0da8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87009 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-13Merge both x64 and x86 CRT merge modules into x64 MSIMike Kaganski
... because it contains x86 binaries in addition to x64: e.g., twain32shim, spsupp_x86. The opposite (inclusion of x64 MSM into x86 MSI) is not possible ( see https://stackoverflow.com/questions/58181986 ), so do it just for x64 MSI. And fix inclusion of CRT MSMs in VS2019, which were detected in configure.ac, but not used in scp2/source/ooo/vc_redist.scp. Change-Id: I3935fce751b1b6d04291fede6b82be25fe541582 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86667 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
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
generated by cgit (git 2.34.1) at 2025-01-13 03:37:14 +0000