summaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2021-04-15vcl PDFiumLibraryTest: clean up not needed HAVE_FEATURE_PDFIUM ifdefsMiklos Vajna
This was already conditional in Module_vcl, so no need to have a duplicated check here. Which allows finally removing the HAVE_FEATURE_PDFIUM ifdef completely. New code can just call vcl::pdf::PDFiumLibrary::get() at runtime and see if the result is nullptr or not. Change-Id: I36508181865a31618e48cf7c2680d75465130dd3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114108 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-04-14update serf to 1.3.9Luboš Luňák
Its build system has switches to scons, so build the library using gbuild. Change-Id: I45b784e65e4987c25baf3fa1477816c744663bf0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114107 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-14disable Skia if --disable -guiLuboš Luňák
There are link errors because of SkiaZone, and Skia is not even linked in for non-GUI. Change-Id: I942dbf79c2012b5dfd4259a7c4ecc680500174b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114111 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-11Get rid of apache-commons-loggingStephan Bergmann
...using Java 1.4 java.util.logging.Logger instead also for the last remaining uses in reportbuilder. (The mention in swext/mediawiki/src/THIRDPARTYLICENSEREADME.html was presumably a leftover from 4b6ceed4a4a9b152905a8b1712ffb9bd61373c16 "swext: Wiki Publisher does not use those apache-commons libraries".) Change-Id: Ia0bc598fe5844ced11cae497548ec7d09453a99d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113939 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-09do not #error in clangplugins with --disable-pchLuboš Luňák
I missed that -building-pch-with-obj is checked by configure (and used) only if PCHs are used. So remove the error checking and hope that it gets checked whenever somebody does changes related to the flag. Change-Id: Ibdf991169f023dae48dad0dd2929215fb048d57d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113841 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-09make clang plugin check code in headers only once if in PCHLuboš Luňák
When using Clang PCHs, we know for certain that the content of a PCH will be used once by the PCH's dedicated source file. So it is not necessary to let clang plugin check locations coming from a PCH every time, but just once when compiling that dedicated source. For starmath's parse.cxx this reduces compilation time 0.94s->0.4s (0.1s when not using plugins at all), for sc's document.cxx it is 5.9s->5.0s (4.0s without plugins). For reference, without PCHs the numbers are (with/without plugins) 2.1s/1.9s for parse.cxx and 11.2s/10.3s for document.cxx. Change-Id: Ie39787e65d7951187941dcff4899d053da63cbdd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113817 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-09upload libmwaw 0.3.18David Tardon
Change-Id: I6ffa01f092455f79bb3690875e1b286ae2298832 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113819 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2021-04-03Add initial support for sccache builds on WNTThorsten Behrens
- gets auto-detected if an sccache binary is in the path - currently external projects using gcc-wrapper are _not_ cached - this needs fixing in the gcc-wrapper - current sccache versions won't work with -Fp (precompiled headers), so while sccache gets called, nothing really is cached. Best build with --enable-pch=no therefore. Change-Id: I78dd7e08ea20ae888236c8c8e8e7a25a405f23b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113530 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-04-02tdf#140229 neon: update to release 0.31.2Jan-Marek Glogowski
I didn't check all commits, but the most likely fix was "Fix hang on SSL connection close with IIS (issue #11)". The server from this bug report is a "Microsoft-IIS/10.0", according to the output from "curl --dump-header". Not sure this bug is critical enough to bump the neon dependency in configure. Change-Id: I3e20bad1aa732641e6f8a83316e58fc7513186c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113495 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-04-01We can surely drop iOS SDKs 12.* nowTor Lillqvist
Change-Id: I67b160432dfdcc2f9e17ec31bc9ffc4190438506 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113454 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-03-25tdf#124173: Enable thesauruses in the iOS appTor Lillqvist
Build our lnth library and the external mythes library. Install thesauruses for the app's Xcode project to pick up and include in the app bundle. Look for them in the place where they will end up. To get thesauruses you need to configure with --with-myspell-dicts. Change-Id: I2d850ca3c821c5c764cb061340a265440d04e41b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113066 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113073 Tested-by: Tor Lillqvist <tml@collabora.com>
2021-03-24use --enable-ooenv only if --enable-debug/dbgutilLuboš Luňák
I'm not sure what the original purpose of the ooenv script was, but now it contains only debugging settings such as malloc debugging, which has a noticeable overhead (8.2s->10.1s in my random case). At least openSUSE appears to not actually package the script, but it still doesn't make sense to use this script in non-debug builds. Change-Id: I4518bb1680a543ed520399c11c83dd6dc5539f71 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112999 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-03-23Rename LO Windows arm64 ID to aarch64Jan-Marek Glogowski
The Windows platform is called Arm64. But now that the ID for Mac is also going to be renamed from arm64 to aarch64, this get's rid of the arm64 as the UNO identifier and user in gbuild, just like on all other Arm64 platforms. Change-Id: I60a7eafd04b426f17b6e41ad9a09e6405c0d4173 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112973 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-03-23WIN always check jdk_home path and contentJan-Marek Glogowski
Change-Id: If13984395051c3e507028312a4106059f3f0bb93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112972 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-03-23Make PLATFORMID=macosx_aarch64 match RTL_ARCH=AARCH64Stephan Bergmann
e.g. Extension_test-passive generated a workdir/Extension/test-passive.oxt META-INF/manifest.xml containing m:media-type="application/vnd.sun.star.uno-components;platform=macosx_arm64" from PLATFORMID (see solenv/gbuild/Extension.mk), but dp_misc::platform_fits (desktop/source/deployment/misc/dp_platform.cxx) matches that platform attribute's architecture substring ("arm64") against dp_misc::StrCPU::get(), i.e., RTL_ARCH ("aarch64"), which thus failed. Change-Id: I82896d6b01948aaa9461d7027ffce25dcf245aac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112889 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Jenkins
2021-03-22Drop external owncloud-android-libMichael Weghorn
It's no longer used by Android Viewer and use in the online-based Android app has already been removed in online commit commit 2a52d768dd61f2ef8fedccb32f015c9095915935 Date: Wed Feb 19 09:05:56 2020 +0100 android shell: Remove the 'storage framework', we have content providers. Change-Id: I468c7121eb495eb8b1a8892f14f2c289b94b7a93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112766 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-03-20fix system zxing buildRene Engelhard
Change-Id: I248471718def63f85525c49d46855340cde4b222 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112789 Tested-by: René Engelhard <rene@debian.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-03-20tdf#139778 qrcodegen library removal.homeboy445
It was replaced by ZXing library. Change-Id: I49eb809586c7b4ba3a93fd77f804bfc93fead669 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112701 Reviewed-by: René Engelhard <rene@debian.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2021-03-20tdf#139778 bundle external:zxing libhomeboy445
Change-Id: I0023f6ce8315427b1a3deaf755e78ae06475b08c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112053 Reviewed-by: René Engelhard <rene@debian.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: René Engelhard <rene@debian.org> Tested-by: Jenkins
2021-03-17tdf#124909: Use the myspell dictionary for Swiss German on iOSTor Lillqvist
The iOS system German dictionary is not good for Swiss German. (And it doesn't even claim to be, it says it is for de_DE.) The system German dictionary accepts 'ß' but that is not used in Swiss German, 'ss' is always used instead. Build the spell library for iOS, too, and don't assume that the system de_DE dictionary would be usable for de_CH and de_LI. Copy those dictionaries for inclusion in the iOS app bundle. Change-Id: I0f8020812221024756c792bddc16a707de35b827 Signed-off-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112603 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112635
2021-03-16Do build Pdfium for iOS, tooTor Lillqvist
For it to compile, the inclusion of <Carbon/Carbon.h> had to be replaced with <CoreGraphics/CoreGraphics.h>. That doesn't harm the macOS build either. This fixes the crash in https://github.com/CollaboraOnline/online/issues/1710 . I am not entirely sure yet whether the actual PDF import functionality now then works in the iOS app, though. Change-Id: Ie25e7c58632c0fdddb569d58217f23b26d1e5937 Signed-off-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112571 Tested-by: Jenkins
2021-03-15configure: fix detection of CLANGDIRMichael Stahl
... for values of CXX like "sccache clang++" - take the first word that contains "clang". Change-Id: Icb4406fdaad73e593e5d7086bc726f8e1b017acd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112479 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-03-15GCC trunk already calls it C++23Stephan Bergmann
...since <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=78739c2df788ee5c868d998a6333d453317d8711> "c++: Add support for -std=c++23" Change-Id: I28e345b4130f04eb37a1acb736a4ccbf2f577451 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112392 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-28Upgrade fuzzers to LIB_FUZZING_ENGINEAndrzej Hunt
And check that LIB_FUZZING_ENGINE is set during configure. Because: 1. It's easier to build locally this way (you don't need to build or hack a libFuzzingEngine.a - instead you can just specify LIB_FUZZING_ENGINE=-fsanitize=fuzzer to produce a valid build). 2. Using -lFuzzingEngine is deprecated [1] for various reasons [2]. The old behaviour can be emulated if desired by setting LIB_FUZZING_ENGINE=-lFuzzingEngine . This patch was tested as follows: - Building LO within oss-fuzz via: python infra/helper.py build_fuzzers --sanitizer address libreoffice </path/to/patched-libreoffice-core> python infra/helper.py check_build libreoffice - Building LO fuzzers standalone via: export CC="clang-11" export CXX="clang++-11 -stdlib=libc++" export CFLAGS="-fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION" export CXXFLAGS="$CFLAGS -stdlib=libc++" export LDFLAGS="$CFLAGS -Wl,--compress-debug-sections,zlib -lpthread" export LIB_FUZZING_ENGINE=-fsanitize=fuzzer ./autogen.sh --with-distro=LibreOfficeOssFuzz --with-system-libxml make fuzzers (--with-system-libxml only appears to be needed because of issues specific to my build environment/Suse 15.2. I'm invoking clang-11 simply because that's the most modern clang I have installed, plain clang should also work on most sufficiently modern systems). [1] https://github.com/google/oss-fuzz/blob/481280c65048fd12fb2141b9225af511a9ef7ed2/infra/presubmit.py#L46 [2] https://github.com/google/oss-fuzz/issues/2164 Change-Id: Iddb577c30a39620e72372ef6c2d3fda67f8aabdf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111691 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-02-19python3: upgrade to release 3.8.8rc1Michael Stahl
Fixes CVE-2021-3177 plus these less important ones: CVE-2021-23336 CVE-2020-27619 CVE-2020-26116 CVE-2019-20907 Change-Id: Idbe072a9db1faf8363b4f7795b9fde71c26969f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111208 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-02-18On aarch64 platform deb package platform string should be arm64 actuallyAndras Timar
Change-Id: I0b4b04e4a6f5c474b3961e5223128e0c835b8c44 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111096 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2021-02-17More targeted suppression of bogus GCC -Werror=stringop-overflow=Stephan Bergmann
...given that <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296#c5> "[8/9/10/11 Regression] -Wstringop-overflow false positive due to using MEM_REF type of &MEM" is declared fixed now on GCC 11 trunk. (Moving -Wno-stringop-overflow from gb_CFLAGS_WERROR to gb_CXXFLAGS_COMMON is done for no other reason than to harmonize this with the code for the similar HAVE_BROKEN_GCC_WMAYBE_UNINITIALIZED.) Change-Id: I3468138c9bbda28f754d4162cb9c059796bd3932 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111029 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-09configure.ac: allow --enable-python=system on macOS if PYTHON is non-emptyAndrew Udvare
This will work as long as a valid Python is in PATH, such as /usr/bin/python3 from Xcode or another version in some prefix like /opt/local. Change-Id: Ic967c3ce2f9949d94c11c3449363841a1565cfa9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108486 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-02-04don't need FindBin if --disable-openssl usedCaolán McNamara
Change-Id: I786ca760b8f4e606945acfc9b2667c2305c014d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110378 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-01-28mac: allow cross compiling with host/build x86_64-apple-macosChristian Lohmaier
apple silicon supports to cross compile without special build-tools/full cross-compiling setup, so just always pass the build/host for firebird. firebird and nss don't recognize the -macos specifier, so substitute it by -darwin to make those happy… Change-Id: I953317fc87da2a20dc91acd88c8528796c3b2a69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110093 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-01-26Accept iOS SDK 14.4Tor Lillqvist
Change-Id: Ibb7800fe407ec6145fed4bb7903b18d40eba9d37 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109997 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-01-21Avoid Clang -Werror,-Wunused-command-line-argumentStephan Bergmann
> [CXX] bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx > clang-12: error: argument unused during compilation: '-fno-stack-clash-protection' [-Werror,-Wunused-command-line-argument] as seen e.g. on macOS 11.1 ARM64 when building against Clang 12 trunk. Clang supports -fstack-clash-protection on > $ clang --target=x86_64-unknown-linux-gnu -fstack-clash-protection -fsyntax-only -x c - </dev/null but not on e.g. > $ clang --target=aarch64-unknown-linux-gnu -fstack-clash-protection -fsyntax-only -x c - </dev/null > clang-12: warning: argument unused during compilation: '-fstack-clash-protection' [-Wunused-command-line-argument] or > $ clang --target=arm64-apple-macosx11.0.0 -fstack-clash-protection -fsyntax-only -x c - </dev/null > clang-12: warning: argument unused during compilation: '-fstack-clash-protection' [-Wunused-command-line-argument] Change-Id: I98625bb7ed37bf00e97634c1c8d1f87fe3263af9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109719 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-21Use C++20 consteval for the Color(sal_uInt32) ctorStephan Bergmann
...to make it more obvious that, since 63a68064bb33f180b8a231f7524d99405d910226 "make the Color constructors explicitly specify transparency", it should only be called when the argument is known at compile-time to have no transparency/alpha channel. (This revealed a GCC bug causing bogus > xmloff/source/chart/ColorPropertySet.cxx: In constructor ‘xmloff::chart::ColorPropertySet::ColorPropertySet(Color)’: > xmloff/source/chart/ColorPropertySet.cxx:81:9: error: ‘this’ is not a constant expression > 81 | m_nDefaultColor( 0x0099ccff ) // blue 8 > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ so in configure.ac suppress HAVE_CPP_CONSTEVAL when the compiler is found broken.) Change-Id: I68df7bd5fbd9b2dcf2243b5a4bde4064d3d665fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109697 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-19add --disable-librelogo to disable LibreLogo at build timeMichael Stahl
Annoyingly the packinfo_*.txt don't support conditionals but we can work-around that with a little duplication. Change-Id: Id00a6831effcc63a917fc21d2cd201474fdb559d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109569 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-01-14Bump MSVC baseline to Visual Studio 2019 version 16.5Stephan Bergmann
After b4b7e92cbf5a212cc1c648af86df2dee364d48c8 "Use MSVC's /permissive- to make it more standards conforming", vmiklos reported that his 16.4.6 build started to fail with > C:/lo/master/connectivity/source/drivers/odbc/OStatement.cxx(411): error C2760: syntax error: unexpected token 'identifier', expected 'type specifier' > C:/lo/master/connectivity/source/drivers/odbc/OStatement.cxx(411): note: This diagnostic occurred in the compiler generated function 'T connectivity::odbc::OStatement_Base::getStmtOption(SQLINTEGER) const' > C:/lo/master/connectivity/source/drivers/odbc/OStatement.cxx(418): error C2760: syntax error: unexpected token 'identifier', expected 'type specifier' > C:/lo/master/connectivity/source/drivers/odbc/OStatement.cxx(418): note: This diagnostic occurred in the compiler generated function 'SQLRETURN connectivity::odbc::OStatement_Base::setStmtOption(SQLINTEGER,T) const' > [build CXX] connectivity/source/drivers/odbc/ODatabaseMetaData.cxx > make[1]: *** [C:/lo/master/solenv/gbuild/LinkTarget.mk:301: C:/lo/master/workdir/CxxObject/connectivity/source/drivers/odbc/OStatement.o] Error 2 > make[1]: *** Waiting for unfinished jobs.... > C:/lo/master/connectivity/source/drivers/odbc/ODatabaseMetaDataResultSet.cxx(161): error C3861: 'checkDisposed': identifier not found > C:/lo/master/connectivity/source/drivers/odbc/ODatabaseMetaDataResultSet.cxx(161): note: 'checkDisposed': function declaration must be available as none of the arguments depend on a template parameter > C:/lo/master/connectivity/source/drivers/odbc/ODatabaseMetaDataResultSet.cxx(161): note: This diagnostic occurred in the compiler generated function 'T connectivity::odbc::ODatabaseMetaDataResultSet::getInteger(sal_Int32)' > make[1]: *** [C:/lo/master/solenv/gbuild/LinkTarget.mk:298: C:/lo/master/workdir/CxxObject/connectivity/source/drivers/odbc/ODatabaseMetaDataResultSet.o] Error 2 while it succeeded after upgrading to 16.8.4. That change had been seen working with 16.5.4 (on tb73, see <https://lists.freedesktop.org/archives/libreoffice/2021-January/086635.html> "Heads up: Use MSVC's /permissive- to make it more standards conforming"), so lets hope that bumping the baseline from 16.4 to 16.5 is all that is needed. Change-Id: I7446f778a94e15e7ea5c8ef0780bf10831a2d4b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109293 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-14Resolves tdf#139343 and tdf#139335 - Community/Enterprise flavorHeiko Tietze
* Switch CE/EE per --disable-community-flavor internally use HAVE_FEATURE_COMMUNITY_FLAVOR * Version info in about dialog shows text depending on this flavor * Start center also shows the brand image now * TDF builds use a brand image with TDF tagline in the about dialog * Brand images with just "Community" (no Edition) Change-Id: I363dd2b39df9aad951c9d79addf9bdedfc4a3495 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108980 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-01-13Use MSVC's /permissive- to make it more standards conformingStephan Bergmann
<https://docs.microsoft.com/en-us/cpp/build/reference/ permissive-standards-conformance?view=msvc-160> states: "Starting in Visual Studio 2019 version 16.8, the /std:c++latest option implicitly sets the /permissive- option." We opt-in to /std:c++latest via --with-latest-c++, which I'm using for my local Windows builds, so I already happened to fix all the /permissivie- issues across our code base when I upgraded to MSVC 16.8 (at first being unaware why those issues started to show up for me, then understanding that it was due to my use of --with-latest-c++ and this MSVC 16.8 change). Change-Id: I29779ad7d3c2bb0f3615e16e377a8ea220d9e5f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108961 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-25Remove vlc part since experimental since 5 yearsJulien Nabet
However considering git history about vlc part (see https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=vlc) it seems there's no real patch since 2013 + it's been explicitely indicated as experimental since 2015 See http://document-foundation-mail-archive.969070.n3.nabble.com/About-vcl-status-in-avmedia-keep-or-removed-unmaintained-code-since-7-years-tt4293282.html Of course if someone wants to keep on the work on it, it's always possible to revert the patch. Change-Id: Ia1602ea61b7ffa577148a80f974ebdcb71495fbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108283 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-12-23Don't lock galleries build into DESKTOPJan-Marek Glogowski
And add the missing dependency of Executable_gengal on Package_svx_gengal, so the actual executable script is created in instdir_for_build for the cross-toolset. Change-Id: I98ea1d58273c871f0a3b804a93970eedfb7f8908 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108108 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-12-22That wasn't a reliable way to detect Apple JDKStephan Bergmann
The check had been introduced with 16c0807d75cfd9ecbca9c703ed0eadda80529aab "configure: reject Apple JDK", but with 7db048f62929a9d267b63db3a6ea2b58b47ec757 "Manually select JDK outside /Library/Java/JavaVirtualMachines on macOS" it works fine to configure --with-jdk-home= a (non-Apple) JDK installed outside /Library/Java/JavaVirtualMachines. If anybody thinks a check to reject Apple JDK would still be useful, and knows a reliable way to detect it, feel free to add back a fixed check. Change-Id: I18910d992e3d1fc6fd8fc4b9d522aec0cce3e652 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108144 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-21Retire the bit-rotting LibreOfficeLight iOS appTor Lillqvist
Change-Id: I21b8055fc97d8dfb8429e7dafa1a3982c3b7499b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108122 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-21add -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED to gtk cflagsCaolán McNamara
Change-Id: If642e9ec03a092375acb9b0624e62eec33ebd716 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108063 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-19cross-compile: make sure configure fails if build-side configure failsChristian Lohmaier
testing for existance of config_host.mk is flawed/doesn't catch all kind of errors and thus gives false "OK" for incremental builds and not even for builds after make clean see also d691b46e52d173cf945130df01bd35b5c4c0f539 Change-Id: I153f585c3a7870ef4a87848eccf7abd7d66987e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107970 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-12-18cross-compilation targets really do need all AC_CONFIG_FILESChristian Lohmaier
Build doesn't fail after just a make clean, but do fail with a completely fresh checkout regression from https://gerrit.libreoffice.org/c/core/+/107655 Change-Id: Id05f747548729449fbda6306fc27e35377b80569
2020-12-15Accept iOS SDK 14.3Tor Lillqvist
Change-Id: I7b13905840616fe84a1b9d23161c4c349d2e7f0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107778 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-15Accept macOS SDK 11.1Tor Lillqvist
Change-Id: Ief4322005fb9087c00f767dcd50a59f2ccbc8a82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107744 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-15add a visual studio code workspace template (created by configure.ac)Christian Lohmaier
Not having settings directly stored in .vscode directory in the repository/having the files ignored there is a problem when you build in a separate builddirectory and you regularly do a full reset of your sourcedir using "git clean -fdx" and similar. If you had any folder-settings, you'd lose them that way. VS Code doesn't really have a mechanism to include and then extend repository defaults, but it has three different tiers where settings are pulled from: folder, workspace and user For LibreOffice core repository there are no folder settings as our .vscode is not populated (or at least it is not stable), a user can of course place a settings.json or other configuration files in their checkout, just with the "git clean" problem mentioned above. This patch adds a workspace configuration - that file can be stored anywhere and instead references the folders to use as configuration items. If you want to add your own launch configuration or tasks: you can just store it on your desktop, and can completely wipe out your builddir as well as prune your srcdir - if you reuse the same paths for your next build, you can simply reopen that workspace file and have all your settings applied. Having it part of the core repository and created by configure from the template is thus just a convenience thing - it has a launch-in-debugger rule and settings for code search/browsing that should be all that's needed/all that's specific to LibreOffice at least. Change-Id: I8625d83d0c30c2668b99ec672c651c3d35258ca5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107655 Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-12-14Handle explicit --disable-macosx-package-signingStephan Bergmann
Change-Id: Ib524049405215ac96ad51cbdc7f527f29c4f83f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107693 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-03At least Clang 12 trunk understands -std=c++2b nowStephan Bergmann
...since <https://github.com/llvm/llvm-project/commit/ 6627a3c2873fdf7ccba1a1573371079be48b36e8> "[c++2b] Add option -std=c++2b to enable support for potential C++2b features." Change-Id: I56b689c740c4269fa5ee29976ed8b0c17a04e6a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107175 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-03Replace unowinreg.dll with execution of `reg QUERY`Stephan Bergmann
The SDK's <https://wiki.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/ Transparent_Use_of_Office_UNO_Components> on all platforms included the Windows- specific unowinreg.dll in generated jars (so that those jars, when distributed to a Windows environment, would find a LO installation by inspecting the Windows registry). That unowinreg.dll was originally built as a 32-bit DLL (though when building a 64-bit Windows LO, it happened to be built as a 64-bit DLL). For non-Windows LO builds, it could either be built locally with a MinGW toolchain (--enable-build-unowinreg) or downloaded from dev-www.libreoffice.org. However, that had various issues: For one, unowinreg.dll was not necessarily available in a distributed jar as a 64-bit DLL for use with a 64-bit JRE on Windows. (Theoretically, running such a jar with a 32-bit JRE to access a 64-bit LO installation's URE jars could have worked. But practically, those URE jars in turn require native DLLs, which would then not have been available as 32-bit DLLs for use in the 32-bit JRE.) For another, at least the unowinreg.dll resulting from --enable-build-unowinreg on Fedora 33 would have had a dependency on libgcc_s_dw2-1.dll that would generally not have been available in a target Windows environment. There appears to be no pure Java way to read the Windows registry, but instead of using a native code DLL for that, it appears to work just as well to call out to reg.exe and parse its output. This removes the --enable-build-unowinreg and --with-mingw-cross-compiler configuration options. (The sole use of the MinGW toolchain in LO was for building unowinreg.dll.) Change-Id: I3283ea38c884d3221a205e5ab6ec99a2691ef474 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107140 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
generated by cgit (git 2.34.1) at 2024-05-29 23:50:22 +0000