summaryrefslogtreecommitdiff
path: root/external
AgeCommit message (Collapse)AuthorFilesLines
2020-10-28external/cairo: Fix another UBSan invalid-shift-baseStephan Bergmann1-0/+11
> pixman-utils.c:217:14: runtime error: left shift of 155 by 24 places cannot be represented in type 'int' ...which happened once while using the LO GUI Change-Id: I174a29e240f09576859308ada56fe240881f0dad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104915 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-20external/cairo: Support building with ASan/UBSanStephan Bergmann4-1/+288
A full `make check screenshot` required lots of little "harmless" fixes in pixman and cairo to address: > cairo-image-compositor.c:133:34: runtime error: left shift of 255 by 24 places cannot be represented in type 'int' during CppunitTest_emfio_emf > pixman-fast-path.c:3089:23: runtime error: left shift of 255 by 24 places cannot be represented in type 'int' during CppunitTest_emfio_emf > pixman-sse2.c:5019:17: runtime error: load of misaligned address 0x7f99303dbac5 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment during CppunitTest_emfio_emf > cairo-fixed-private.h:64:14: runtime error: left shift of negative value -8388608 during CppunitTest_emfio_wmf > pixman-sse2.c:6443:20: runtime error: left shift of 198 by 24 places cannot be represented in type 'int' during CppunitTest_filter_svg > pixman-sse2.c:5976:6: runtime error: load of misaligned address 0x629000163202 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment during CppunitTest_filter_svg > pixman-sse2.c:3259:10: runtime error: load of misaligned address 0x606000c85761 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment during CppunitTest_oox_vml > pixman-sse2.c:521:18: runtime error: load of misaligned address 0x607000ca9d41 for type 'const uint32_t' (aka 'const unsigned int'), which requires 4 byte alignment during CppunitTest_oox_vml > pixman-gradient-walker.c:196:14: runtime error: left shift of 255 by 24 places cannot be represented in type 'int' during CppunitTest_sc_tiledrendering > pixman-combine32.c:786:1: runtime error: left shift of 255 by 24 places cannot be represented in type 'int32_t' (aka 'int') during CppunitTest_vcl_backend_test > pixman-fast-path.c:2761:29: runtime error: left shift of negative value -99 during CppunitTest_xmloff_draw > pixman-bits-image.c:243:31: runtime error: left shift of negative value -99 during CppunitTest_xmloff_draw > pixman-bits-image.c:244:31: runtime error: left shift of negative value -9 during CppunitTest_sd_tiledrendering > pixman-fast-path.c:2762:29: runtime error: left shift of negative value -84 during CppunitTest_sw_rtfexport2 > cairo-gstate.c:2300:14: runtime error: null pointer passed as argument 1, which is declared to never be null during CppunitTest_sw_ooxmlexport8 > pixman-access.c:389:2: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' during CppunitTest_sw_ooxmlexport15 > ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ff264ae275c at pc 0x7ff238941795 bp 0x7fff6bbadb10 sp 0x7fff6bbadb08 > READ of size 4 at 0x7ff264ae275c thread T0 > #0 in _add_clipped_edge at workdir/UnpackedTarball/cairo/src/cairo-polygon.c:351:24 (instdir/program/libcairo.so.2 +0x88c794) during CppunitTest_sw_odfexport > cairo-tor-scan-converter.c:1619:34: runtime error: left shift of negative value -39 during CppunitTest_sw_odfexport > ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fe6ca085750 at pc 0x000000325c3a bp 0x7fff899bedd0 sp 0x7fff899be580 > READ of size 16 at 0x7fe6ca085750 thread T0 > #0 in __asan_memcpy at /home/sbergman/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 (workdir/LinkTarget/Executable/cppunittester +0x325c39) during CppunitTest_sw_odfexport > pixman-sse2.c:3352:14: runtime error: left shift of 65535 by 16 places cannot be represented in type 'int' during CppunitTest_sw_odfexport > cairo-gstate.c:2355:14: runtime error: null pointer passed as argument 1, which is declared to never be null during CppunitTest_basctl_dialogs_test > pixman-sse2.c:3537:10: runtime error: load of misaligned address 0x615000167682 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment during CppunitTest_sc_screenshots > cairo-image-source.c:512:10: runtime error: load of misaligned address 0x6180037aee6f for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment during UITest_writer_tests7 Change-Id: Icd2a211df4751d8dbfd5903bfba424b4c4672999 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104572 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-20Unbreak nss build for the native arm64 on an Apple Silicon MacTor Lillqvist1-1/+1
I had managed to break it with 92b99bddb63b1bf4a639fc969727ac35b3ed1ac8 that made it possible to build for (Rosettafied) x86_64 on an Apple Silicon Mac. Change-Id: I337f2a8e777394e586f659fadd819cf7dfc0a332 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104546 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2020-10-18pdfium: add reading of line points to the wrapperTomaž Vajngerl2-0/+49
Change-Id: I3e596254b2e4ecc9f56ff09eeb63b66195ea6a2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104376 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-10-16Rename CLANG_CC, CLANG_CXX configuration vars (avoid clash with scan-build)Stephan Bergmann2-9/+9
Clang's scan-build tool uses the CLANG_CXX environment variable (setting it up in the scan-build script to pass it to the ccc-analyzer script), but happens to erroneously set it to a non-existing path (see <https://reviews.llvm.org/D89481> "[scan-build] Fix clang++ pathname again"). So wrapping LO's autogen.sh and make in scan-build picked up that broken CLANG_CXX and caused build failures like > [CXX] external/skia/source/SkMemory_malloc.cxx > /bin/sh: ~/llvm/inst/bin/clang-12++: No such file or directory (see <https://lists.freedesktop.org/archives/libreoffice/2020-October/086113.html> "Re: llvm/clang static analyzer reports"). So rename CLANG_CXX, and for consistency also CLANG_CC and the various CLANG_CXXFLAGS_INTRINSICS_*, by prefixing each with LO_. Change-Id: Ib41cabe940f8bfb1997f74e865cca5725f859e07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104383 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-15pdfium: add support for border property of PDF annotationsTomaž Vajngerl2-0/+61
This extends PDFium with readon of "Border" property from the PDF annotations and adds the API to PDFium wrapper. Border is mostly used for border (line) width and the radius of rounding of the border (for drawing a rounded rectangle for example). Change-Id: I03f189eee03155ec699b2f56ceed23e6839a3f03 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104361 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-10-14Fix build for Intel on an Apple Silicon MacTor Lillqvist1-0/+3
Change-Id: Id1a5906db87b05218b0810045c698e5ab2a09eca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104271 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-10-11Related tdf#122560 tdf#135202: build plugin caching_sha2_pw for MariaDb/MysqlJulien Nabet1-0/+1
Taking a look at: https://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authentication.html "caching_sha2_password" is better than "sha256_password" plugin Notice that "sha2" in "caching_sha2_password" refers, as the quoted url indicates: 'more generally to the SHA-2 class of encryption algorithms, of which 256-bit encryption is one instance' Change-Id: Icbbe45f4f20345da2fb5a262b4d85bce3a1fecd9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104172 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-10-08external/liborcus: Missing includesStephan Bergmann2-0/+31
...as seen with recent GCC 11 trunk libstdc++: > orcus_xlsx.cpp: In function ‘size_t orcus::{anonymous}::get_schema_rank(orcus::schema_t)’: > orcus_xlsx.cpp:313:59: error: incomplete type ‘std::numeric_limits<long unsigned int>’ used in nested name specifier > 313 | return it == rank_map.end() ? numeric_limits<size_t>::max() : it->second; > | ^~~ etc. Change-Id: If92cfb565ed9344b2ec1403793d7aeff8bd019ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104074 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-08track dirty areas for Skia drawingLuboš Luňák2-0/+115
Updates to the screen in raster mode aren't _that_ slow, in fact it seems using SkRegion can make things slower because of manipulating the region, but with SkIRect this could sometimes help a bit. It also appears that StretchDIBits() that is used by the Windows raster code doesn't work correctly if only a subset of the y-axis range is specified, which reduces the usefulness. Change-Id: Ia93d2b60f2c62461e4c2c81210ab1d5d652a2cfb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104047 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-10-08Related tdf#135202: declare libmariadb/secure/win_crypt in mk file for MariaDBJulien Nabet1-0/+1
Change-Id: Ib9634d9e88d7e97a5c03ff4d8b7808c598c3b8bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104040 Tested-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-10-05Fix nss build for iOSTor Lillqvist1-2/+2
Change-Id: Ib7d1fdfc8394c7356db436e5d1bf6126c164bacc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103937 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-10-04pdfium: Support for InkStrokes and VerticesTomaž Vajngerl2-0/+157
This extends PDFium with getting InkStrokes and Vertices for annotations, which wasn't implemented before, and adds support to PDFium wrapper in LibreOffice. Change-Id: I570d53038a59ab830fcd5639583c75cf8adda86c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103885 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-10-02nss: restore manual pre-dependency buildJan-Marek Glogowski4-5/+86
We had some seldom build failures on Windows, with errors like: PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: '..../nssckmdt.h'. This happens, because of the "." / parent shell hack. Thinking about it again, it doesn't prevent the parent make to run in parallel to the "." directory make. So I tried to use a terminal match-all rule like ifneq (,$(filter .,$(DIRS))) %:: # empty terminal rule triggered $(error can't happen) endif to stop the original parent make, but that doesn't work and the $(error ...) is triggered. So AFAIK I'm out of options here and have to restore the old manual pre-dependency build variant - still much better then no parallel build. An alternative idea was to put the rest of the rules.mk in the "else" of the terminal rule, to skip all normal rules, but this still leaves out all rules from the rest of the make-files, which might result in some hard to debug errors. This reverts my upstream patch 15608:744881490c78. Change-Id: I9e2e9e1ec9f35697c7853c92f60434f514cba5ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103777 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-10-02skia: fix Windows Arm64 buildJan-Marek Glogowski1-0/+4
This uses MSVC instead of clang for this host. Change-Id: Idf96668e00563be12a7819a1658b657673733d21 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103780 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-10-01icu: fix Windows Cygwin cross buildJan-Marek Glogowski4-80/+133
This replaces the previous, broken Windows ARM64 solution with a general fix for Cygwin cross-building. The main problem is the PATH environment, because that is colon-seperated on Cygwin, like on Unix, so won't work with any absolute "Windows" path, which is needed for the --with-cross-build option. One general change is the adoption of icucross.inc. I don't know, why that should prefer the general CURR_FULL_DIR from icudefs.mk over the specific one in @platform_make_fragment@. That breaks here, because it returns a cygwin unix path, which is used as an option to compiled tools, which these won't be able to handle. Change-Id: Ic2cf15b48801ac57ea5a8a2876ce59f2a84edfb3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103759 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-10-01icu: fix Windows extras buildJan-Marek Glogowski3-4/+48
Based on an upstream patch, with an additional hunk to fix the debug build. Gets rid of a difference between Windows and other builds. Change-Id: I597a5cb429fb3257535d8a2ce1142f5f9f34cebe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103758 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-10-01exteranl/coinmp: Fix build with recent GCC 11 trunkStephan Bergmann2-0/+34
It had started to fail for me now with > ~/gcc/trunk/inst/bin/g++ -DHAVE_CONFIG_H -I. -I. -O -MT CoinFinite.lo -MD -MP -MF .deps/CoinFinite.Tpo -c CoinFinite.cpp -fPIC -DPIC -o .libs/CoinFinite.o > CoinFinite.cpp: In function 'bool CoinFinite(double)': > CoinFinite.cpp:38:19: error: 'DBL_MAX' was not declared in this scope > 38 | return val != DBL_MAX && val != -DBL_MAX; > | ^~~~~~~ > CoinFinite.cpp:8:1: note: 'DBL_MAX' is defined in header '<cfloat>'; did you forget to '#include <cfloat>'? > 7 | #include "CoinUtilsConfig.h" > +++ |+#include <cfloat> > 8 | because of a missing -DCOINUTILS_BUILD. Which in turn was caused by workdir/UnpackedTarball/coinmp/CoinUtils/configure (see workdir/UnpackedTarball/coinmp/CoinUtils/config.log), which first tries to determine an ac_declaration that would apparently be a suitable declaration of `exit` without actually including <stdlib.h> in a C++ file. It settles on > configure:3551: ~/gcc/trunk/inst/bin/g++ -c -g -O2 conftest.cc >&5 > conftest.cc:15:17: warning: 'void std::exit(int)' has not been declared within 'std' > 15 | extern "C" void std::exit (int) throw (); using std::exit; > | ^~~ > <built-in>: note: only here as a 'friend' > configure:3557: $? = 0 (which generates a warning, but no error with the given g++ invocation). The determined ac_declaration value is then included in confdefs.h, causing the later > configure:4014: ~/gcc/trunk/inst/bin/g++ -o conftest -O3 -pipe -DNDEBUG -pedantic-errors -Wparentheses -Wreturn-type -Wcast-qual -Wall -Wpointer-arith -Wwrite-strings -Wconversion -Wno-unknown-pragmas -Wno-long-long -DCOINUTILS_BUILD -Wl,-z,origin -Wl,-rpath,\$$ORIGIN conftest.cc >&5 > conftest.cc:15:17: error: 'void std::exit(int)' has not been declared within 'std' > 15 | extern "C" void std::exit (int) throw (); using std::exit; > | ^~~ > <built-in>: note: only here as a 'friend' > configure:4020: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "CoinUtils" > | #define PACKAGE_TARNAME "coinutils" > | #define PACKAGE_VERSION "2.9.11" > | #define PACKAGE_STRING "CoinUtils 2.9.11" > | #define PACKAGE_BUGREPORT "http://projects.coin-or.org/CoinUtils" > | #define COINUTILS_VERSION "2.9.11" > | #define COINUTILS_VERSION_MAJOR 2 > | #define COINUTILS_VERSION_MINOR 9 > | #define COINUTILS_VERSION_RELEASE 11 > | #define COIN_COINUTILS_VERBOSITY 0 > | #define COIN_COINUTILS_CHECKLEVEL 0 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | > | int > | main () > | { > | int i=0; i++; > | ; > | return 0; > | } > configure:4045: WARNING: The flags CXXFLAGS="-O3 -pipe -DNDEBUG -pedantic-errors -Wparentheses -Wreturn-type -Wcast-qual -Wall -Wpointer-arith -Wwrite-strings -Wconversion -Wno-unknown-pragmas -Wno-long-long -DCOINUTILS_BUILD" do not work. I will now just try '-O', but you might want to set CXXFLAGS manually. to fail, because its g++ invocation including -pedantic-errors turns that > 'void std::exit(int)' has not been declared within 'std' warning into an error. There were similar build failures in the Cgl, > ~/gcc/trunk/inst/bin/g++ -DHAVE_CONFIG_H -I. -I. -I~/lo/core/workdir/UnpackedTarball/coinmp/CoinUtils/src -DCOIN_HAS_CLP -O -MT ClpCholeskyDense.lo -MD -MP -MF .deps/ClpCholeskyDense.Tpo -c ClpCholeskyDense.cpp -fPIC -DPIC -o .libs/ClpCholeskyDense.o > In file included from ClpCholeskyDense.cpp:11: > ClpHelperFunctions.hpp:16:4: error: #error "don't have header file for math" > 16 | # error "don't have header file for math" > | ^~~~~ > In file included from ClpCholeskyDense.cpp:11: > ClpHelperFunctions.hpp: In function 'double CoinSqrt(double)': > ClpHelperFunctions.hpp:81:13: error: 'sqrt' was not declared in this scope > 81 | return sqrt(x); > | ^~~~ and Clp, > ~/gcc/trunk/inst/bin/g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./.. -I./../CglGomory -I~/lo/core/workdir/UnpackedTarball/coinmp/CoinUtils/src -I~/lo/core/workdir/UnpackedTarball/coinmp/Osi/src/Osi -I~/lo/core/workdir/UnpackedTarball/coinmp/CoinUtils/src -I~/lo/core/workdir/UnpackedTarball/coinmp/Clp/src/OsiClp -I~/lo/core/workdir/UnpackedTarball/coinmp/Clp/src -I~/lo/core/workdir/UnpackedTarball/coinmp/CoinUtils/src -I~/lo/core/workdir/UnpackedTarball/coinmp/Osi/src/Osi -O -MT CglLandPValidator.lo -MD -MP -MF .deps/CglLandPValidator.Tpo -c CglLandPValidator.cpp -fPIC -DPIC -o .libs/CglLandPValidator.o > CglLandPValidator.cpp: In member function 'int LAP::Validator::cleanCut(OsiRowCut&, const double*, const OsiSolverInterface&, const CglParam&, const double*, const double*)': > CglLandPValidator.cpp:66:22: error: 'fabs' was not declared in this scope; did you mean 'labs'? > 66 | double val = fabs(elems[i]); > | ^~~~ > | labs > CglLandPValidator.cpp: In member function 'int LAP::Validator::cleanCut2(OsiRowCut&, const double*, const OsiSolverInterface&, const CglParam&, const double*, const double*)': > CglLandPValidator.cpp:189:23: error: 'fabs' was not declared in this scope; did you mean 'labs'? > 189 | double smallest = fabs(rhs); > | ^~~~ > | labs subdirectories, and which happened to get solved by the same approach of removing problematic ac_declaration values from configure. I am not sure what all that magic of determining that ac_declaration value is supposed to be good for. There appears to be no trace of it in the corresponding configure.ac sources, so it likely was automatically added by some dated autotools (all three configure files mention "Generated by GNU Autoconf 2.59"). At least on a cursory look, the determined ac_declaration appears to only be used in configure itself, and not leak into the actual coinmp build stage, so dropping the problematic ac_declaration values is hopefully harmless. These three subdirectories were all that failed for me, but there might still be silent issues in other subdirectories when a problematic ac_declaration value would negatively affect other configure checks. (An alternative approach could be to regenerate all the configure files from their configure.ac sources with a recent autotools. But at least some of the existing external/coinmp/*.patch* already change such configure files, which would need to be adapted.) Change-Id: I0a33b0f654800e8288d3ca28e26a64efc23a3f6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103756 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-30use -fpch-codegen rather than -fmodules-codegenLuboš Luňák1-1/+1
The -fmodules-codegen flag has been in Clang for quite a while, but it officially works with PCHs only with Clang11+, and even there's it's better to use the properly named -fpch-codegen. This also fixes a problem with Clang9 having only -fmodules-codegen but not the -fno-* variant, causing the build to break. Change-Id: I9a8c979426f95e8c1f77cbeab1df64390d7243b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103677 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-30icu: fix Windows Arm64 buildJan-Marek Glogowski3-8/+91
I couldn't find a general solution to select the correct build path when cross compiling for Windows Arm64, so this just adds the patch in exactly this case, which WFM. Change-Id: I6e53e1531048404b70dcf61eab0a7f4021076868 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102852 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-29Update liborcus to 0.16.1.Kohei Yoshida2-377/+0
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 Tardon1-0/+6
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 Tardon2-4/+6
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 Vajna1-0/+31
... 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 Vajna2-0/+12
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 Bergmann2-0/+16
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 Lillqvist5-16/+224
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 McNamara1-0/+4
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 McNamara3-4/+6
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 Glogowski2-0/+787
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 Glogowski1-1/+1
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 Glogowski3-0/+1527
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 Glogowski1-0/+3
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 Glogowski3-0/+73
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 Vajna2-6/+3
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ňák1-0/+1
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 Kaganski1-1/+2
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 Glogowski5-16/+6
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 Yoshida6-413/+0
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 Yoshida8-12/+394
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 Glogowski16-0/+16
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 Glogowski1-2/+2
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 Glogowski3-19/+14
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 Glogowski1-1/+2
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 Yoshida3-130/+0
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 Bergmann2-0/+22
...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ňák1-2/+2
'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 Bergmann2-0/+14
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 McNamara1-4/+5
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 Kaganski1-0/+14
... 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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-24 17:34:06 +0000