summaryrefslogtreecommitdiff
path: root/external
AgeCommit message (Collapse)Author
2020-09-29Update liborcus to 0.16.1.Kohei Yoshida
Change-Id: I27e87278545c1d41381b1ab8a49f6f6a07681bfb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103590 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2020-09-28upload libmwaw 0.3.17David Tardon
Change-Id: I24c6c5a5d93a76a9fcc2213cd48beb8e5a5ca479 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103519 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2020-09-27upload libwps 0.4.12David Tardon
Change-Id: Ib787098b98f68185c1b3f6b414efbec36cad02dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102332 Tested-by: David Tardon <dtardon@redhat.com> Reviewed-by: David Tardon <dtardon@redhat.com>
2020-09-25Related: tdf#136980 cairo: avoid linking to freetype-2.8-only ...Miklos Vajna
... FT_Get_Var_Design_Coordinates This is meant to help producing binaries which run on Ubuntu 16.04. Change-Id: I7fc965c265d2ac97a6836df0829d3d4cd0cc9333 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103392 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-25tdf#136980 cairo: avoid linking to freetype-2.8 symbolsMiklos Vajna
This is meant to help producing binaries on CentOS 7 which run on Ubuntu 16.04, when using internal cairo. Change-Id: Ie4cd3fe707225a951ec8a5fb49a755064701dcfa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103378 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-25external/icu: Fix #include <numbers> under --with-latest-c++ -std=c++20Stephan Bergmann
Not sure why I started to get that failure exactly now, but with --with-latest-c++ enabling -std=c++20, builds with GCC (at least GCC 11 trunk) on Fedora 32 now failed with > In file included from ~/gcc/trunk/inst/include/c++/11.0.0/bits/max_size_type.h:37, > from ~/gcc/trunk/inst/include/c++/11.0.0/bits/ranges_base.h:38, > from ~/gcc/trunk/inst/include/c++/11.0.0/string_view:44, > from ~/gcc/trunk/inst/include/c++/11.0.0/bits/basic_string.h:48, > from ~/gcc/trunk/inst/include/c++/11.0.0/string:55, > from ~/gcc/trunk/inst/include/c++/11.0.0/bits/locale_classes.h:40, > from ~/gcc/trunk/inst/include/c++/11.0.0/bits/ios_base.h:41, > from ~/gcc/trunk/inst/include/c++/11.0.0/streambuf:41, > from ~/gcc/trunk/inst/include/c++/11.0.0/bits/streambuf_iterator.h:35, > from ~/gcc/trunk/inst/include/c++/11.0.0/iterator:66, > from ~/gcc/trunk/inst/include/c++/11.0.0/bits/ranges_algobase.h:36, > from ~/gcc/trunk/inst/include/c++/11.0.0/bits/ranges_uninitialized.h:36, > from ~/gcc/trunk/inst/include/c++/11.0.0/memory:69, > from ../common/unicode/localpointer.h:45, > from ../common/unicode/uenum.h:23, > from ../common/unicode/ucnv.h:53, > from unicode/ustdio.h:31, > from ufile.cpp:32: > ~/gcc/trunk/inst/include/c++/11.0.0/numbers:139:9: error: unable to find numeric literal operator ‘operator""Q’ > 139 | = 2.718281828459045235360287471352662498Q; > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~/gcc/trunk/inst/include/c++/11.0.0/numbers:139:9: note: use ‘-fext-numeric-literals’ to enable more built-in suffixes etc. But the reason to #undef __STRICT_ANSI__ (which is set by -std=c++... vs. -std=gnu++...) in workdir/UnpackedTarball/icu/source/io/ufile.cpp appears to be obsolete, at least on Fedora 32 <stdio.h> does declare fileno (which is a POSIX extension) under -std=c++... just fine. Change-Id: I3707418db56d7fe9946655ab27bf1bf8eb479a1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103371 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-23tdf#128136: Build curl, nss, and xmlsec for iOS, tooTor Lillqvist
We must link nss statically, including the three dylibs that normally are loaded at run-time, because including bare dylibs in an iOS appp on the App Store is not OK. See https://developer.apple.com/forums/thread/125796 . For linking the softokn3 library statically, NSS already had code, behind NSS_STATIC_SOFTOKEN ifdefs. Introduce two more macros: NSS_STATIC_FREEBL for the freebl library and NSS_STATIC_PKCS11 for the nssckbi library. Turn off parallelism for the sub-make building nss. There seems to be race conditions or something when running simultaneous instances of the nsinstall.py script or the nsinstall program in nss (used when building nss for the build platform). When cross-compiling from macOS, use python3 to run the nsinstall.py script, as it is Python 3. Change-Id: Idd427b5ebf21f802b3feb0d5a3d259317ba8fc67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103106 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103218 Tested-by: Jenkins
2020-09-21add an explicit --disable-qrcodegen configure optionCaolán McNamara
Change-Id: If8e965fa955aecdb9e7011bdddc690de9cad0c4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103120 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21update pchesCaolán McNamara
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-17cppunit: fix Windows Arm64 buildJan-Marek Glogowski
Change-Id: I75b169362ed703bcae0720aeac0602f389435317 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102857 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-17pdfium: fix Windows Arm64 buildJan-Marek Glogowski
Change-Id: Ie8698bd51b897ba8d07c278cbbd9ad2d3caa4bb3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102856 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-17lcms2: fix Windows Arm64 buildJan-Marek Glogowski
Adds the ARM64 platform to the VC2019 MSBuild solution. This turned out to be tricky, because - for whatever reason - diff couldn't detect the solution file as text, so I added the whole file to replace it. And "-a" would just generate a UTF-16 diff, which is not applyable, so this just adds the new file and copies it. Change-Id: I538610bed071fd45dc107f405056f23e1bff7a09 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102855 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-17python3: fix Windows Arm64 buildJan-Marek Glogowski
Change-Id: I2e9f9ca5fcf40a3ff53c036ebc51a75b882d91f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102854 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-17nss: fix Windows Arm64 buildJan-Marek Glogowski
Change-Id: I59834daebd6c9ccd1255be6f08e5f61b20ee06e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102853 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-16external: update pdfium to 4260Miklos Vajna
Change-Id: I1b6c7e9991b2e35921f7f849380d940c6662b174 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102787 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-15disable Clang's -fmodules-codegen for Skia if optimizing itLuboš Luňák
Skia is explicitly made to build optimized even in debug builds, unless --enable-skia=debug is given, so $(PCH_MODULES_CODEGEN) gets set even for it by com_GCC_class.mk , although normally it's disabled for optimized builds as not worth it. Explicitly disable the flag for Skia. Change-Id: Icf030f0bdc99dbc476af585937c864f951d2b7ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102674 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-15Set PYTHONWARNINGS to error by default for --enable-werrorMike Kaganski
Setting it in environment overrides this setting. The rationale is to avoid introducing warnings like these appeared recently: zipfile.py:1517: UserWarning: Duplicate name: 'cmd/ar/sc_bulletsandnumberingdialog.png' (see e.g. https://ci.libreoffice.org/job/gerrit_windows/71910/consoleFull) Change-Id: I8ae42e039ec3d028c01dbc4bcf422feae9e46271 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100268 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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>
generated by cgit (git 2.34.1) at 2025-02-01 07:41:17 +0000