summaryrefslogtreecommitdiff
path: root/external
AgeCommit message (Collapse)Author
2020-09-15WIN add and apply default msbuild platform+configJan-Marek Glogowski
Adds three Windows gb_* variables: - gb_MSBUILD_CONFIG_AND_PLATFORM can be passed as msbuild flags - gb_MSBUILD_PLATFORM maps debug / release settings - gb_MSBUILD_CONFIG maps the CPUTYPE to the default msbuild names and converts the users in external projects. Change-Id: Ie9b817721180d78d104db11c44241e4b3e46bba9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102701 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-12Remove unused patches.Kohei Yoshida
Change-Id: I2a1dbe15f2df42b4f74e0c00b91ace6c0d3f5f8e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102503 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2020-09-12Upgrade liborcus to 0.16.0.Kohei Yoshida
Change-Id: Iae29fb26417dfc161698a81bee84e81545969065 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102502 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2020-09-11cross-build: fix Java NI linkingJan-Marek Glogowski
LibreOffice has a JNI component on Windows and Linux, the officebean. Therefore we need a host JDK for linkage to the jawt, and a build JDK to compile the Java code. Change-Id: I4138628ab3ea2ef5900a5b4e9281050ae84e4eb5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102483 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11WIN cross: fix libjpeg-turbo buildJan-Marek Glogowski
Change-Id: Iae4696df714ba27c0053f7ca3eb485816e8e58c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102481 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11WIN cross: fix gpg-related library buildsJan-Marek Glogowski
Cross compiling these libraries requires to supply the cross- compiler via the CC_FOR_BUILD environment variable. Since we have to use the gcc-wrappers, we now need two different invocations with different inclues and libraries, but just have fixed environment variables. Also, the CC_FOR_BUILD clashes with LO's own variant, but that is easy to fix. So this change includes: - gcc-wrappers: new option --wrapper-env-prefix to add a prefix to the environment variable names - gcc-wrappers: new option --wrapper-print-cmdline to dump the real command called, when a verbose build is executed - gcc-wrappers: default to exe, if the output has no extension - unify build flags for gpg related libraries Change-Id: I4e6a6ba3c6e09237c8ffefa40ce61131290a3852 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102482 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11Fix the minimal build-tools targetJan-Marek Glogowski
The revert commits change the build-tools target for a DESKTOP build to build the complete LO. This restores the original, minimal one and also adds a whitelist of allowd build types. OpenCL needs a configure switch, as it's status is also stored in a config header, so preventing the build is not enough. This also reverts: - commit 802161a505272732566210e9ebbd8fe1b23fb86d - commit 02d931a59e2966d0c2736db8dee7be3e3dcd6bae Change-Id: Ibfcb0c54e72da1b7c2e63c082ea6586520a787fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102480 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-10Upgrade mdds to 1.7.0.Kohei Yoshida
Change-Id: I2a66017fb5f93ecd39dbf980aa04798dbd33b3e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102343 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2020-09-09external/pdfium: Work around GCC C++20 recursive comparison issueStephan Bergmann
...that caused CppunitTest_xmlsecurity_pdfsigning to crash with recent GCC and --with-latest-c++ due to an infinite recursion at [...] > #260048 0x00007fe0dbf91a4f in fxcrt::operator==<CPDF_Array const, CPDF_Object>(CPDF_Object const*, fxcrt::RetainPtr<CPDF_Array const> const&) (lhs=0x2342870, rhs=...) at workdir/UnpackedTarball/pdfium/core/fxcrt/retain_ptr.h:140 > #260049 0x00007fe0dbf91a4f in fxcrt::operator==<CPDF_Array const, CPDF_Object>(CPDF_Object const*, fxcrt::RetainPtr<CPDF_Array const> const&) (lhs=0x2342870, rhs=...) at workdir/UnpackedTarball/pdfium/core/fxcrt/retain_ptr.h:140 > #260050 0x00007fe0dbf8e30d in (anonymous namespace)::CPDF_DeviceNCS::v_Load(CPDF_Document*, CPDF_Array const*, std::__debug::set<CPDF_Object const*, std::less<CPDF_Object const*>, std::allocator<CPDF_Object const*> >*) (this=0x1956e30, pDoc=0x172a770, pArray=0x2343320, pVisited=0x7ffcf2f2dd50) at workdir/UnpackedTarball/pdfium/core/fpdfapi/page/cpdf_colorspace.cpp:1299 > #260051 0x00007fe0dbf8a73f in CPDF_ColorSpace::Load(CPDF_Document*, CPDF_Object const*, std::__debug::set<CPDF_Object const*, std::less<CPDF_Object const*>, std::allocator<CPDF_Object const*> >*) (pDoc=0x172a770, pObj=0x2343320, pVisited=0x7ffcf2f2dd50) at workdir/UnpackedTarball/pdfium/core/fpdfapi/page/cpdf_colorspace.cpp:545 > #260052 0x00007fe0dbfa4c01 in CPDF_DocPageData::GetColorSpaceInternal(CPDF_Object const*, CPDF_Dictionary const*, std::__debug::set<CPDF_Object const*, std::less<CPDF_Object const*>, std::allocator<CPDF_Object const*> >*, std::__debug::set<CPDF_Object const*, std::less<CPDF_Object const*>, std::allocator<CPDF_Object const*> >*) (this=0x1737a70, pCSObj=0x2343320, pResources=0x0, pVisited=0x7ffcf2f2dd50, pVisitedInternal=0x7ffcf2f2dcc0) at workdir/UnpackedTarball/pdfium/core/fpdfapi/page/cpdf_docpagedata.cpp:317 [...] (See the linked GCC bug report for further details.) Change-Id: I8cc1ff0b6e5693b987e6c6c9b2efed7990d0869f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102330 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-03fix offsets in our SSSE3 Skia functions (tdf#136326)Luboš Luňák
'src' is uint32_t, so that extra '*4' was wrong. Change-Id: Ie0628a72bd4f7eb3122e4b1d67b6bb759f74bc46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102007 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-03external/redland: Honour LIBXML_CFLAGS/LIBS in raptor's configureStephan Bergmann
I ran into this issue with a somewhat special setup on macOS, with both Xcode 11 and Xcode 12 beta installed, and > xcode-select -s /Applications/Xcode-beta.app/Contents/Developer and > CC/CXX=... -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk ... to make the LO build use the latest SDK from Xcode 12 beta. (And with implicit --with-system-libxml, and with recent Clang 12 trunk.) However, even though raptor's configure receives our LIBXML_CFLAGS/LIBS env vars from config_host.mk, it always overrides them with output from some $XML_CONFIG tool. For whatever reason, in my setup that caused raptor's LIBXML_CFLAGS to be set to > -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include (And a similar reference to that /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk in LIBXML_LIBS. That MacOSX.sdk directory symlinks to some /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk. I don't know about that /Library/Developer/CommandLineTools/SDKs tree, but it smells like it is maintained by Xcode and not properly adapted for my Xcode 12 beta install.) Anyway, that LIBXML_CFLAGS ends up on raptor's compiler command lines, causing them to contain > ... -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk ... -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include ... so that something like > #include <stdio.h> in workdir/UnpackedTarball/raptor/src/raptor_parse.c will include > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h rather than > /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk/usr/include/stdio.h and consider the former not to be a system header, and thus emit warnings/errors like > In file included from raptor_parse.c:30: > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:220:5: error: 'TARGET_OS_EMBEDDED' is not defined, evaluates to 0 [-Werror,-Wundef-prefix=TARGET_OS_] > #if TARGET_OS_EMBEDDED > ^ that it would suppress from system headers. Raptor's configure appears to always override LIBXML_CFLAGS/LIBS since <https://github.com/dajobe/raptor/commit/ 7da03ba5cd6e45ea41afebd4955acf6e96e9d622> "Switch libxml and libcurl to use PKG_PROG_PKG_CONFIG and PKG_CHECK_MODULES", which looks like a bug to me. (Trying to prevent that code from being executed by passing in --without-xml2-config, similar to the existing --without-xslt-config in external/redland/ExternalProject_raptor.mk, would fail with > configure: error: libxml2 is not available - please get it from http://xmlsoft.org/ from raptor's configure, apparently suppressing libxml2 detection altogether.) Change-Id: I5f2813e849bb61c0af48df0579abe87d3671185b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101991 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-27remove some unused includes and update pchesCaolán McNamara
Change-Id: I786548bef39fa711aabcff32b592b3fdc4a6f9fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101486 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-27Fix `--disable-pch` buildMike Kaganski
... breaking after commit eaf4f6d3b1e64bc7b057e70cffe0bda0ed42c49f with this: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/tools/sk_app/win/VulkanWindowContext_win.cpp:13: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/VulkanWindowContext.h:17: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\include/gpu/vk/GrVkBackendContext.h:11: C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(141,12): error: member access into incomplete type 'GrDirectContext' obj->ref(); ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(226,40): note: in instantiation of function template specialization 'SkSafeRef<GrDirectContext>' requested here sk_sp(const sk_sp<T>& that) : fPtr(SkSafeRef(that.get())) {} ^ C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/WindowContext.h(24,1): note: in instantiation of member function 'sk_sp<GrDirectContext>::sk_sp' requested here WindowContext { ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkImage.h(36,7): note: forward declaration of 'GrDirectContext' class GrDirectContext; ^ In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/tools/sk_app/win/VulkanWindowContext_win.cpp:13: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/VulkanWindowContext.h:17: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\include/gpu/vk/GrVkBackendContext.h:11: C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(150,12): error: member access into incomplete type 'GrDirectContext' obj->unref(); ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(251,9): note: in instantiation of function template specialization 'SkSafeUnref<GrDirectContext>' requested here SkSafeUnref(fPtr); ^ C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/WindowContext.h(24,1): note: in instantiation of member function 'sk_sp<GrDirectContext>::~sk_sp' requested here WindowContext { ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkImage.h(36,7): note: forward declaration of 'GrDirectContext' class GrDirectContext; ^ In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/tools/sk_app/win/VulkanWindowContext_win.cpp:13: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/VulkanWindowContext.h:17: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\include/gpu/vk/GrVkBackendContext.h:11: C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(264,25): error: no matching function for call to 'SkSafeRef' this->reset(SkSafeRef(that.get())); ^~~~~~~~~ C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/WindowContext.h(24,1): note: in instantiation of member function 'sk_sp<GrDirectContext>::operator=' requested here WindowContext { ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(139,40): note: candidate template ignored: substitution failure [with T = GrDirectContext] template <typename T> static inline T* SkSafeRef(T* obj) { ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(311,9): error: no matching function for call to 'SkSafeUnref' SkSafeUnref(oldPtr); ^~~~~~~~~~~ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(264,19): note: in instantiation of member function 'sk_sp<GrDirectContext>::reset' requested here this->reset(SkSafeRef(that.get())); ^ C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/WindowContext.h(24,1): note: in instantiation of member function 'sk_sp<GrDirectContext>::operator=' requested here WindowContext { ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(148,42): note: candidate template ignored: substitution failure [with T = GrDirectContext] template <typename T> static inline void SkSafeUnref(T* obj) { ^ 4 errors generated. Change-Id: I159b9ef388834a454eff58c6c2eda2e13dddb67a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101439 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-08-26UBSan needs sk_app::WindowContext RTTI in Library_vclStephan Bergmann
...as seen during CppunitTest_basic_scanner: > DynamicLibraryManagerException: "Failed to load dynamic library: workdir/LinkTarget/CppunitTest/libtest_basic_scanner.so > instdir/program/libvcllo.so: undefined symbol: _ZTIN6sk_app13WindowContextE" Change-Id: I7c39d19fda3cdfe51b5ccf117ffe5c6c89863258 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101410 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-26update Skia to chrome/m86 snapshotLuboš Luňák
Change-Id: Id0c0679bc1ca546a75f71d4716ba151ae46569bd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101311 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-08-18nss: fix Android buildMichael Stahl
Change-Id: I8d6704a00ee70c1cb397f8f12dac8050f24f44be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100917 Tested-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-16Pass $(verbose) into ExternalProject_icuStephan Bergmann
Change-Id: I4c93d4c4207645795812a0cafb64cbe32a7a520a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100823 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-12SvTreeListBox can move into toolkit headers nowCaolán McNamara
Change-Id: I6b3b6ef1530a192f4b6bf87aa9688687063683ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-12Enable --enable-lto --enable-skia when building with GCC+Clang on LinuxStephan Bergmann
...where all the Library_skia objects are built with Clang, so contain intermediate LLVM bytecode, but were then linked via GCC and ld or gold, which do not understand such object files and thus failed. So in gb_LinkTarget__command_dynamiclink use T_CC/T_CXX also for the linker command line. But then Clang would still be used for linking with the -fuse-ld=(ld or gold) $(USE_LD) suitable for GCC, and would still fail. So break T_USE_LD out of T_LDFLAGS and let gb_LinkTarget_use_clang override T_USE_LD with CLANG_USE_LD. At least for now, that CLANG_USE_LD (containing something like -fuse-ld=lld or -fuse-ld=lld --ld-path=... for the latter see d668c9a04d04d256fcbbd2165fe226f1db88256b "Adapt --enable-ld to Clang 12 trunk --ld-path") needs to manually be passed into autogen.sh, it is not computed in configure.ac. Then building Library_skia would still fail to link against StaticLibrary_libpng, as that only contains intermediate GCC object code, so make sure to build it with -ffat-lto-objects in this specific case. Change-Id: I0a104e53a8898cd9c2eb3b643e21954e853608cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-10external/mariadb-connector-c: ma_bmove_upp is defined twiceStephan Bergmann
...in UnpackedTarball/mariadb-connector-c/libmariadb/bmove_upp and in workdir/UnpackedTarball/mariadb-connector-c/libmariadb/ma_stmt_codec.c. Given that the first of the two contains nothing but that redundant declaration, lets drop it from the (hand-curated?) list of included source files. (I came across this when experimenting with --enable-lto on Linux and temporarily including static libraries as --whole-archive, which thus caused a "multiple definition" error when linking StaticLibrary_mariadb-connector-c into Library_mysqlc.) Change-Id: I8c5f4de476a4bbd036fd25940cdb44d11954ecc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100427 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-10nss: upgrade to release 3.55.0Michael Stahl
Fixes CVE-2020-6829, CVE-2020-12400 CVE-2020-12401 CVE-2020-12403. (also CVE-2020-12402 CVE-2020-12399 in older releases since 3.47) * external/nss/nss.nspr-parallel-win-debug_build.patch: remove, merged upstream Change-Id: I8b48e25ce68a2327cde1420abdaea8f9e51a7888 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100345 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-08external/cppunit: Run tests in deterministic orderStephan Bergmann
What prompted me to make this change is that when I tried an --enable-lto build, CppunitTest_xmlsecurity_signing failed in a non-obvious way, and I noticed that it ran the individual tests in a different order than a --disable-lto build. With this change, CppunitTest_xmlsecurity_signing also started to fail in the --disable-lto build, which has meanwhile been fixed with 800eebfa82106c509310ed43bef38a7a4ad4451f "Database document apparently needs to be closed before it is disposed". No other tests started to fail in my Linux --disable-lto-build with this change, and my Linux --enable-lto build (using recent Fedora 32 GCC 10.2 and the default linker) also succeeds `make check` after 800eebfa82106c509310ed43bef38a7a4ad4451f, both with and without this cppunit change. (<https://bugs.documentfoundation.org/show_bug.cgi?id=126442> "LTO build segfaults in sw_apitests" and <https://src.fedoraproject.org/rpms/libreoffice/c/ 5d644f1606b76ffa4a102433849a824d7293a404> "%check fails with lto enabled" indicate that older branches also fail CppunitTest_sw_apitests with --enable-lto, but I could not reproduce that on current master.) What happens in cppunit is that every CPPUNIT_TEST_SUITE_REGISTRATION (or other macro like CPPUNIT_TEST_FIXTURE internally calling CPPUNIT_TEST_SUITE_REGISTRATION) creates a global static variable whose ctor inserts the address of a sub-object of that global static variable into the TestFactoryRegistry::m_factories set. Even if the order of invocation of those ctors from one .cxx is deterministic, the relative order or the addresses of those sub-objects inserted into the TestFactoryRegistry::m_factories set need not be (though they probably typically are). Another source of nondeterminism is that the order of ctors from different .cxx is not specified (which might have caused the CppunitTest_xmlsecurity_signing failures, given that test includes suites from two different .cxx). So to make test execution more reproducible, make the order in which the tests are run deterministic, sorting them by name. (When TestFactoryRegistry::addTestToSuite the adds the sorted tests to TestSuite::addTest, they are inserted into a TestSuite::m_tests vector, from which point on things appear to already happen in a deterministic order.) Change-Id: I40741f397a96772974fd41bacdb3dd763c885417 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100384 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-07external/cppunit: -g based on --enable-symbols, not --enable-debugStephan Bergmann
Change-Id: I35ceb0069082cb66f1bc09591baace594f0dc030 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100297 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-07Use USE_DLFCN also on macOS on arm64Tor Lillqvist
Change-Id: I8975ea2d4f33a101b5ac6db247a6dd062bc0c410 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100273 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-08-07Update config.{guess,sub} with latest versions and handle fallout of thatTor Lillqvist
From http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD . This time, do not apply the add-on change from 25a09c8776cc6088a5b2bf13dc84eb386c26bb7e to config.sub, but keep it pristine. Instead, let's start using the name "aarch64" instead of "arm64" for macOS and iOS in the autofoo context, as that is what those tools call it. Clang and Apple call it arm64, though. Change-Id: I1e05866c5fb08e0800cdfeaf7f6a71bfb43d1777 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100272 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-08-07Fix Skia build using VS 2019 v.16.7.0 with --disable-pchMike Kaganski
No idea if updated VS makes a difference, or some recent Skia update... In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h:13: C:/lo/src/build/workdir/UnpackedTarball/skia\include/private/SkPathRef.h(113,41): error: implicit instantiation of undefined template 'std::tuple<SkPoint *, float *>' std::tuple<SkPoint*, SkScalar*> growForVerbsInPath(const SkPathRef& path) { ^ C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here class tuple; ^ In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h:13: C:/lo/src/build/workdir/UnpackedTarball/skia\include/private/SkPathRef.h(114,30): error: implicit instantiation of undefined template 'std::tuple<SkPoint *, float *>' return fPathRef->growForVerbsInPath(path); ^ C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here class tuple; ^ In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11: C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h(1543,65): error: implicit instantiation of undefined template 'std::tuple<SkPathVerb, const SkPoint *, const float *>' std::tuple<SkPathVerb, const SkPoint*, const SkScalar*> operator*() const { ^ C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here class tuple; ^ In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11: C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h(1550,20): error: implicit instantiation of undefined template 'std::tuple<SkPathVerb, const SkPoint *, const float *>' return {verb, fPoints + backset, fWeights}; ^ C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here class tuple; ^ In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11: C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h(1625,68): error: implicit instantiation of undefined template 'std::tuple<SkPathVerb, const SkPoint *, const float *>' return (fIter != fEnd) ? static_cast<Verb>(std::get<0>(*fIter)) : kDone_Verb; ^ C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here class tuple; ^ 5 errors generated. make[1]: *** [C:/lo/src/core/solenv/gbuild/LinkTarget.mk:351: C:/lo/src/build/workdir/GenCxxObject/UnpackedTarball/skia/src/core/SkBitmapDevice.o] Error 1 Change-Id: Ica85829cf61d86e486cf4b2a730f50e06e3fb337 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100271 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-08-05gpgpmepp: fix creative abuse of gbuildMichael Stahl
The problem was that (cd sw && make CppunitTest_sw_ooxmlexport4) fails with an error that the gpgmepp package doesn't exist, but only on WNT. Nonobviously, this is due to the override of the rule for the gpgmepp package in ExternalPackage_gpgmepp.mk, which copies the same file that the package already depends on for no obvious reason. Furthermore, RepositoryExternal.mk uses gb_Helper_register_executables_for_install with gpgme-w32spawn, when it should just register the package instead, because that is not a gbuild Executable. Change-Id: I8cb8b7a68c9681844a39de1390aa736a1ec53449 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100159 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-05external/libgpg-error: -Werror,-Wundef (clang-cl)Stephan Bergmann
Change-Id: I7e71411901cc2c09b5d13a5ca451f1981e8a9e44 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100090 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-04external/gpgmepp: Avoid overloaded utf8_to_wchar in C codeStephan Bergmann
> w32-util.c(176,1): error: conflicting types for 'utf8_to_wchar' > utf8_to_wchar (const char *string) > ^ > workdir/UnpackedTarball/libgpg-error/src\gpg-error.h(1109,10): note: previous declaration is here > wchar_t *utf8_to_wchar (const char *string, size_t length, size_t *retlen); > ^ with clang-cl on Windows, while in a case like this where there is only one definition, the mismatching declaration merely gets warned about by MSVC with "warning C4029: declared formal parameter list different from definition". (And on non-Windows that w32-util.c apparently doesn't get compiled at all.) Change-Id: I76cfc3ec086325c527c04dbe0e8341cb9b775c50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100091 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-29optimize a bit more conversions to/from Skia bitmap formatsLuboš Luňák
It turns out this doesn't really matter in practice, since if converting between pixel formats is where time is spent, something higher must be already wrong. But since I've already written this... Change-Id: I25451664d529a9226d2d81b2c424a4f4e5422ad5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99577 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-07-28Adapt --enable-ld to Clang 12 trunk --ld-pathStephan Bergmann
...split from -fuse-ld with <https://github.com/llvm/llvm-project/commit/ 1bc5c84710a8c73ef21295e63c19d10a8c71f2f5> "[Driver] Add --ld-path= and deprecate -fuse-ld=/abs/path and -fuse-ld=rel/path", and now causing warnings (or even errors with -Werror) like '-fuse-ld=' taking a path is deprecated. Use '--ld-path=' instead when --enable-ld is configured as a full path. (--enable-ld was vague whether it supports full paths, but it appeared to work reasonably well at least with old versions of Clang.) Change-Id: I5a7dfd992b56aba78dd3646045fb9a827dc40321 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99569 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-24Name of python.bin-gdb.py must match name of python.bin executableStephan Bergmann
...for gdb to autoload it Change-Id: I9a65a03fe18623181d5791b4596b4416228c6c8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99372 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-23fix internal libpng ppc(64el) buildRene Engelhard
by adding the missing files for VSX. See https://lists.freedesktop.org/archives/libreoffice/2020-July/085564.html ff, Change-Id: Ie368fcfa5cca80b2a7bd13be4add5d9973f3b05f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99337 Tested-by: René Engelhard <rene@debian.org> Tested-by: Jenkins Reviewed-by: René Engelhard <rene@debian.org>
2020-07-22Silence GCC 11 trunk -Werror=nonnull in external/boostStephan Bergmann
...like > In file included from workdir/UnpackedTarball/boost/boost/concept/assert.hpp:35, > from workdir/UnpackedTarball/boost/boost/concept_check.hpp:20, > from workdir/UnpackedTarball/boost/boost/range/concepts.hpp:19, > from workdir/UnpackedTarball/boost/boost/range/size_type.hpp:20, > from workdir/UnpackedTarball/boost/boost/range/size.hpp:21, > from workdir/UnpackedTarball/boost/boost/range/functions.hpp:20, > from workdir/UnpackedTarball/boost/boost/range/iterator_range_core.hpp:38, > from workdir/UnpackedTarball/boost/boost/range/iterator_range.hpp:13, > from external/boost/include/boost/range/iterator_range.hpp:29, > from workdir/UnpackedTarball/boost/boost/range/as_literal.hpp:22, > from workdir/UnpackedTarball/boost/boost/algorithm/string/trim.hpp:19, > from workdir/UnpackedTarball/boost/boost/algorithm/string.hpp:19, > from external/boost/include/boost/algorithm/string.hpp:29, > from sal/cppunittester/cppunittester.cxx:61: > workdir/UnpackedTarball/boost/boost/concept/detail/general.hpp: In instantiation of ‘static void boost::concepts::constraint<Model>::failed() [with Model = boost::algorithm::FinderConcept<boost::algorithm::detail::token_finderF<boost::algorithm::detail::is_any_ofF<char> >, const char*>]’: > workdir/UnpackedTarball/boost/boost/algorithm/string/iter_find.hpp:81:13: required from ‘SequenceSequenceT& boost::algorithm::iter_split(SequenceSequenceT&, RangeT&&, FinderT) [with SequenceSequenceT = std::__debug::vector<std::__cxx11::basic_string<char> >; RangeT = const char*&; FinderT = boost::algorithm::detail::token_finderF<boost::algorithm::detail::is_any_ofF<char> >]’ > workdir/UnpackedTarball/boost/boost/algorithm/string/split.hpp:158:50: required from ‘SequenceSequenceT& boost::algorithm::split(SequenceSequenceT&, RangeT&&, PredicateT, boost::algorithm::token_compress_mode_type) [with SequenceSequenceT = std::__debug::vector<std::__cxx11::basic_string<char> >; RangeT = const char*&; PredicateT = boost::algorithm::detail::is_any_ofF<char>]’ > sal/cppunittester/cppunittester.cxx:303:71: required from here > workdir/UnpackedTarball/boost/boost/concept/detail/general.hpp:47:52: error: ‘this’ pointer null [-Werror=nonnull] > 47 | static void failed() { ((Model*)0)->constraints(); } > | ~~~~~~~~~~~~~~~~~~~~~~~~^~ Change-Id: Ia22b5d510ba41bea138dfcc8d8e0b9eb1e9ad41c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99217 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-22external: update pdfium to 4203Miklos Vajna
Change-Id: Ib712fa5494e5461ef59252a0e832d43eabccbee0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99157 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-07-21external/skia: Fix previous std::result_of_t -> std::invoke_result_t changeStephan Bergmann
...84c412cb8392d306ab87fc06855677612f9938a6 "external/skia: Deprecated std::result_of_t has been removed from C++20" Change-Id: I7d14306039dbcdbc9509471402299d8cbb9e48c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99168 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-21external/libtommath: Avoid -Wsystem-headers warnings/errorsStephan Bergmann
NO_ADDTL_WARNINGS controls whether workdir/UnpackedTarball/libtommath/makefile.include adds -Wsystem-headers (among others) to CFLAGS, which has generally been harmless as we build that external code with warnings not as errors. But Clang 12 trunk <https://github.com/llvm/ llvm-project/commit/f47b8851318d5ec2fa1e7867f3fdb86101cdc1da> "[clang] Enable errors for undefined TARGET_OS_ macros in Darwin driver" now unconditionally added some -Werror=... on Darwin/macOS that would cause the build to fail with > In file included from bncore.c:1: > In file included from ./tommath_private.h:18: > In file included from ./tommath.h:25: > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/stdio.h:220:5: error: 'TARGET_OS_EMBEDDED' is not defined, evaluates to 0 [-Werror,-Wundef-prefix=TARGET_OS_] > #if TARGET_OS_EMBEDDED > ^ at least with Xcode 11.6. Change-Id: I5465b9070ff60da85b9278b0e46dcf6c801fbda6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99116 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-21Pass $(verbose) into ExternalProject_libtommathStephan Bergmann
Change-Id: I8b317c05bf31e3d835cb9d847ea7b7486da62199 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99113 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-20external/gpgmepp: Deprecated std::shared_pointer::unique has been removed...Stephan Bergmann
...from C++20, and is no longer provided at least by VS 2019 16.6.4 when using --with-latest-c++ Change-Id: I1812b4c314febe134a299e42362ca50b495f08d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99081 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-20external/skia: Deprecated std::result_of_t has been removed from C++20Stephan Bergmann
...and is no longer provided at least by VS 2019 16.6.4 when using --with-latest-c++ Change-Id: I4655e2a2b3c4c9411ee6f5b9b42137e1bd7ac3fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99046 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-20external/coinmp: C++17 no longer supports "register"Stephan Bergmann
...and GCC 11 trunk g++ now defaults to C++17, so compilation started to fail with that compiler Change-Id: I792e4c7ff59ad88e5571163d5b2362fdb349667d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99082 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-20external/libffi configure needs MAKEStephan Bergmann
It failed for me on Windows with > config.status: error: in `/cygdrive/c/lo/core/workdir/UnpackedTarball/libffi/x86_64-pc-cygwin': > config.status: error: Something went wrong bootstrapping makefile fragments > for automatic dependency tracking. Try re-running configure with the > '--disable-dependency-tracking' option to at least be able to build > the package (albeit without support for automatic dependency tracking). > See `config.log' for more details > make[1]: *** [C:/lo/core/external/libffi/ExternalProject_libffi.mk:28: C:/lo/core/workdir/ExternalProject/libffi/build] Error 1 because it didn't find any `make` (I only have an /opt/lo/bin/make installed). Change-Id: Id3e119bbe37df446571a6ef293b8fae8e5b36fde Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99034 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-17lcms2: update to 2.11 and use VC2019 solutionJan-Marek Glogowski
Dropped patches: - lcms2-msvc-disable-sse2.patch.1: applied to the VS2010 solution; so actually long unused by LO. - 0017-Upgrade-Visual-studio-2017-15.8.patch.1: not used anymore, because the Windows build now uses the VS2019 solution. The new external/lcms2/c++17.patch.1 explicitly disables the register keywordin the header. Change-Id: Icc6dd2a41d0fc94f00fc1ac7fa5bebc941c2a791 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98734 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-07-17python3: update to 3.8.4Jan-Marek Glogowski
With all the prerequisites in place, LO can be updated to the current Python release. Interestingly I found that Cygwin always seems to use LC_COLLATE=C, probably because the default collation rules are missing. Then there are the changes introduced in "PEP 587 -- Python Initialization Configuration", which appearingly have modified the DLL search path behaviour on Windows, so the OpenSLL DLLs aren't found anymore in the program directory. As a workaround, the OpenSLL and libffi DLLs are now (also) installed into the Python lib dir on Windows. Change-Id: Ib82f7b77213da9c525f8c79a13d128d9eec9ca64 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98437 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-07-17libffi: build DLL on WindowsJan-Marek Glogowski
The build setup is rather horrible, with some minimal gcc MSVC wrapper. But the DLL is a prerequisite for the Python 3.8 build, which dropped the internal libffi. It's also possible to build it statically, but then you have to patch the Python 3 _ctypes msbuild properties. This also defaults to explicit --build and --host settings, even without a cross build, because the predicted name would otherwise differ (*-unknown-* instead of *-pc-*). Additionally a "make install" also fails... Change-Id: Ifb7dac840e23efffb9a5e342560aef9e11e0db79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98436 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-07-17openssl: update to 1.1.1gJan-Marek Glogowski
The OpenSSL 1.1.1 release is currently the only supported version and it already has the Windows Arm64 support I was looking for. This change also explicitly enables thread support, which Python depends on since release 3.7, which removed the --without-threads build option. But the explicit OPENSSL_THREADS was just added in 3.8.4, so the old no-threads build fails now and was wrong since probably much longer. Change-Id: I61d94f966bc59407f213f4a81f0a49d0c05f8948 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98435 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-07-12update pchesCaolán McNamara
Change-Id: I75602277a5a26b012a12f2c4f4b7ff5bb663b0b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98474 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-05Use correct location for the config.{guess,sub} in the postgresql tarballTor Lillqvist
Change-Id: Iccec53f67ab6c9e7920354f6a26c81300c1bee48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98097 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-07-05Remove leftover thing for macOS on x86Tor Lillqvist
Change-Id: I353e854c3deb7d1df3767e2295aef68e9491f0e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98144 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-07-05Use up-to-date config.{guess,sub} for external/xmlsec, tooTor Lillqvist
Change-Id: Ib6beab0aa9bf72af83520020eeca6e20a9ecc3df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98096 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
generated by cgit (git 2.34.1) at 2025-01-24 16:02:51 +0000