summaryrefslogtreecommitdiff
path: root/external
AgeCommit message (Collapse)AuthorFilesLines
2020-02-01make update_pch also consider files in <module>/src/**/incLuboš Luňák2-2/+8
With --enable-pch=full there's not much difference between a "public" header in <module>/inc and a private one in <module>/src/somewhere/inc . And since the script searches recursively, this apparently helps to find even more headers for lower pch levels. Change-Id: I8483d0aa5b4fea5a59107c20a8aa5f1ef694af0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87799 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-02-01remove outdated TODO from skia externalLuboš Luňák1-1/+0
Change-Id: Ibe17072dd0c1f4b7f76d05a2dac0e2cbf1eb151d
2020-02-01Skia: fix #define MemoryBarrier coming from winnt.h from pchMike Kaganski1-0/+13
... resulting in error message C:/lo/src/build/workdir/UnpackedTarball/skia/src/gpu/gl/GrGLGpu.cpp(3771): error C2039: 'f__faststorefence': is not a member of 'GrGLInterface::Functions' Change-Id: If69c0067abe287dd276c685cde6be3b31a1ce950 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87780 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-01-31update Skia to chrome/m81Luboš Luňák5-37/+63
Change-Id: I62ac293ac5fde3716b2db1421301f3a4aed0bcc9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87763 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-24python3+WIN: don't fail copy of openssl DLLs+PDBsJan-Marek Glogowski1-0/+15
The LO python3 target fails for me on Windows with: C:\lode\dev\core\workdir\UnpackedTarball\python3\PCBuild\openssl.props(24,5): error MSB3030: Datei "C:/lode/dev/core/workdir/UnpackedTarball/openssl/out32dll\libcrypto-1_1.dll" konnte nicht kopiert werden, da die Datei nicht gefunden wurde. [C:\lode\dev\core\workdir\UnpackedTarball\python3\PCBuild\_ssl.vcxproj] Same for "C:/lode/dev/core/workdir/UnpackedTarball/openssl/out32dll\libssl-1_1.pdb" "C:/lode/dev/core/workdir/UnpackedTarball/openssl/out32dll\libcrypto-1_1.pdb" "C:/lode/dev/core/workdir/UnpackedTarball/openssl/out32dll\libssl-1_1.dll" Other files were also renamed in a previous hunk of this patch. For other people these failures are silently ignored, but they show up in their python3 build.log. But my msbuild version 15.9.21+g9802d43bc3 from VS2017 fails hard on these errors. So this just adapt the pdb and dll names to match the previous renames, which passes the copy calls, so the build continues. Change-Id: Iffc848c334caec534f6e99f8bf83a42da570bbb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87358 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Jenkins
2020-01-23pdfium: don't patch out the COMPONENT_BUILD check, define itMiklos Vajna3-23/+1
So next time we update, no need to adapt a failing patch. Change-Id: I785f16047d1decbf922177fdde4bc6aad7cfebfc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87215 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-01-18external/pdfium: C++20 comparison operator fixStephan Bergmann2-0/+14
Missing const leads to overload resolution ambiguity when a synthesized candidate of operator == for a reversed-argument rewrite conflicts with the actual operator ==, due to the asymmetric const-ness of the implicit object parameter and the RHS parameter: > In file included from workdir/UnpackedTarball/pdfium/core/fxge/cfx_font.cpp:7: > In file included from workdir/UnpackedTarball/pdfium/core/fxge/cfx_font.h:11: > llvm/inst/include/c++/v1/vector:1369:27: error: use of overloaded operator '!=' is ambiguous (with operand types 'std::__1::__vector_base<unsigned char, FxAllocAllocator<unsigned char> >::allocator_type' (aka 'FxAllocAllocator<unsigned char>') and 'std::__1::__vector_base<unsigned char, FxAllocAllocator<unsigned char> >::allocator_type') > if (__base::__alloc() != __c.__alloc()) > ~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~ > llvm/inst/include/c++/v1/vector:1359:5: note: in instantiation of member function 'std::__1::vector<unsigned char, FxAllocAllocator<unsigned char> >::__move_assign' requested here > __move_assign(__x, integral_constant<bool, > ^ > workdir/UnpackedTarball/pdfium/core/fxge/cfx_font.cpp:384:24: note: in instantiation of member function 'std::__1::vector<unsigned char, FxAllocAllocator<unsigned char> >::operator=' requested here > m_FontDataAllocation = std::vector<uint8_t, FxAllocAllocator<uint8_t>>( > ^ > workdir/UnpackedTarball/pdfium/core/fxcrt/fx_memory_wrappers.h:74:8: note: candidate function > bool operator!=(const FxAllocAllocator& that) { return false; } > ^ > workdir/UnpackedTarball/pdfium/core/fxcrt/fx_memory_wrappers.h:73:8: note: candidate function > bool operator==(const FxAllocAllocator& that) { return true; } > ^ > workdir/UnpackedTarball/pdfium/core/fxcrt/fx_memory_wrappers.h:73:8: note: candidate function (with reversed parameter order) Change-Id: I48cfc8ce37287d9d3c0dec8c4d8b14b53de895d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86993 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-17tdf#127619: external/nss: Load smime3 lib with a path on macOSStephan Bergmann2-0/+26
A plain dlopen("libsmime3.dylib",...) would search (among other places) DYLD_FALLBACK_LIBRARY_PATH, which when unset defaults to a set of paths including /usr/local/lib (so would erroneously find Homebrew's /usr/local/lib/libsmime3.dylib instead of LO's LibreOffice.app/Contents/Frameworks/libsmime3.dylib next to the calling LibreOffice.app/Contents/Frameworks/libnspr4.dylib). At least macOS 10.15.2 supports a "@loader_path/" prefix in dlopen, to find the requested library next to the calling code, so use that as a quick fix. (Should that turn out to be problematic, there is PORT_LoadLibraryFromOrigin in workdir/UnpackedTarball/nss/nss/lib/util/secload.c that might be useful in a more elaborate fix.) Change-Id: I8688606017a4b32a2dd55740f67b8fdb36fc5435 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86966 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-17For now, work around Clang 11 -flax-vector-conversion=integer in external/skiaStephan Bergmann2-0/+12
<https://github.com/llvm/llvm-project/commit/ b72a8c65e4e34779b6bc9e466203f553f5294486> "PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer" broke the build with > In file included from /data/sbergman/lo-clang/core/workdir/UnpackedTarball/skia/src/core/SkOpts.cpp:43: > /data/sbergman/lo-clang/core/workdir/UnpackedTarball/skia/src/opts/SkRasterPipeline_opts.h:713:26: error: no matching function for call to '_mm_and_ps' > return _mm_or_ps(_mm_and_ps(c, t), _mm_andnot_ps(c, e)); > ^~~~~~~~~~ > /data/sbergman/llvm/inst/lib/clang/11.0.0/include/xmmintrin.h:404:1: note: candidate function not viable: no known conversion from 'sse2::I32' (aka 'V<int32_t>') to '__m128' (vector of 4 'float' values) for 1st argument > _mm_and_ps(__m128 __a, __m128 __b) > ^ etc. We could pass in -flax-vector-conversions=all on the compiler command line for Clang 11, but that option is not understood by older versions, so for now just disable the failing JUMPER_IS_SSE2/JUMPER_IS_SSE41 code paths. Ultimately, the skia code will need to be fixed. Change-Id: If3202789f5f08bb40cf2ad8f6bcef5b5b3e462dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86939 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-15external: update pdfium to 4021Miklos Vajna4-26/+22
Change-Id: I1c3280e811bf65641bf559e3f01bc62e609548f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86811 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-01-15Bump boost version to 1.71David Ostrovsky4-575/+4
Change-Id: Ica4aba467aa00236a4d1c5b0411d1ebc657ea4df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86594 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-14fix Skia CPU instruction set support (tdf#129546)Luboš Luňák3-9/+27
It was a mistake to compile the SkOpts.cpp file with the highest CPU set available. I got confused by what SK_CPU_SSE_LEVEL means. That setting is the lowest set supported, so we should leave it at whatever Skia's SkPreConfig.h detects it to be from the actual compiler flags (the ones used for building everything). SkOpts::init() does runtime checks only for sets _lower_ than what SK_CPU_SSE_LEVEL says, so by compiling the file with the highest set all these runtime checks got disabled and it was assumed that the set defined by SK_CPU_SSE_LEVEL is always available. Change-Id: I839370645a9cafbede2d37017b9332cc739fc317 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86682 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-14crashtesting: libstaroffice should use sender-lastname not send-lastnameCaolán McNamara2-0/+29
https://github.com/fosnola/libstaroffice/pull/7 Change-Id: Id4fe0bd016cf57d1b48055775d03cfc859ac557b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86715 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-01-09python3: bundle libffi for GNU/Linux buildsMichael Stahl7-2/+86
CPython commit f40d4ddff3c800b3c956a5e8820aabe3aa87cddd "Closes #27979: Remove bundled copy of libffi" causes a bit of a problem because it turns out that libffi isn't all that stable; there's libffi.so.5 on CentOS 6, libffi.so.6 on CentOS 7 and libffi.so.7 on lo_daily_update_gandalf tinderbox. So we have to bundle it in LO; it's only used on GNU/Linux currently. CPython commit 32119e10b792ad7ee4e5f951a2d89ddbaf111cc5 "bpo-35947: Update Windows to the current version of libffi (GH-11797)" also removes the libffi for MSVC, so in a future python upgrade we will have to build libffi for MSVC too. The libffi fork for MacOSX is still in CPython git master. (regression from b10be5d48433076f0b7238d818020f708553e114) Change-Id: Ibc20cf8cd3614cf9941b6970662bd930496776b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86493 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-09python3: fix 32-bit x86 buildMichael Stahl1-1/+1
The reinvented wheel needs another subst. Change-Id: I5bc01b0213f00d383cf971d34f0dc2a9e6817ab9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86480 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-08python3: remove _uuid moduleMichael Stahl1-1/+0
Of course the autotetection in setup.py strikes again, the build will fail if the user doesn't have libuuid-devel installed; we'd need to add a check to LO's configure.ac for libuuid. Let's just not ship it, not sure if anybody needs it. Change-Id: I9079309da7d9c16e666fbab30542365124f97860 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86433 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-08python3: upgrade to release 3.7.6Michael Stahl14-453/+95
* external/python3/python-3.3.3-aix.patch.1: most of it doesn't apply and AIX port isn't maintained anyway so remove it for now * external/python3/ubsan.patch.0: apparently one of the files was removed * 0001-3.6-bpo-17239-Disable-external-entities-in-SAX-parse.patch.1: fixed upstream * python3-osx-avoid-new-10.13.patch.1: replace with simply passing ac_cv_func_utimensat=no to configure * external/python3/python-3.5.4-ssl.patch.1: project files to build OpenSSL removed upstream * There have been changes to how python locates OpenSSL; new variables OPENSSL_INCLUDES etc; it turns out that you have to pass one directory to --with-openssl, as the variables cannot be passed * libuuid.so.1 is a new dependency of the _uuid module * libffi.so.6 is a new dependency of the _ctypes module (the bundled copy of libffi for non-Darwin platforms was removed) * python-3.3.0-pythreadstate.patch.1: the PyThreadState functions have been changed such that CppunitTest_services asserts when there is a PyThreadAttach on top of PyThreadDetach on top of PyThreadAttach, i.e., 2 PyThreadState per thread (PyGILState_Check() fails). Instead of patching in additional workarounds, change PyThreadAttach so that it re-uses an existing PyThreadState if one exists for the thread. Change-Id: I24c19d79b43a30709261fd9db66312b2e3872fd9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84765 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-06avoid Skia assert on leaked resourcesLuboš Luňák1-9/+13
Change-Id: Ie9d9117c43d19b9391f8e0dee6825076aaa12706 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85582 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-12-29skia: make gcc not crash for x86 buildsThorsten Behrens2-0/+21
Otherwise at least on x86, gcc bails out with an ICE: skia/third_party/skcms/src/Transform_inl.h: In function ‘void baseline::clut(const skcms_A2B*, baseline::F*, baseline::F*, baseline::F*, baseline::F)’: skia/third_party/skcms/src/Transform_inl.h:695:13: note: The ABI for passing parameters with 16-byte alignment has changed in GCC 4.6 static void clut(const skcms_A2B* a2b, F* r, F* g, F* b, F a) { ^~~~ skia/third_party/skcms/skcms.cpp: At global scope: skia/third_party/skcms/skcms.cpp:2613:1: internal compiler error: Segmentation fault } ^ Likely reason: optimizer stumbles over F being non-register-passable, c.f. https://stackoverflow.com/questions/39383193/compiling-legacy-gcc-code-with-avx-vector-warnings Fix is an obvious bandaid, but fixes build for CentOS7 devtoolset-7. I suspect though that non-avx/sse2 builds are not a supported scenario for skia, in the end... Change-Id: Iaff734de8dc8b9a6fbf868c13810074f9667720b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85933 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-12-24update cppunit to 1.15.1Markus Mohrhard4-79/+7
Change-Id: Ic27a77addb409a8d63ea44136a8d2410ee40c4d2 Reviewed-on: https://gerrit.libreoffice.org/85539 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2019-12-20tdf#129519 Fix crash during WebDAV lock refreshThorsten Behrens2-0/+23
- NeonSession is shared amongst several files (if on the same server instance) - there's explicit code in DAVSessionFactory::createDAVSession() to share sessions for same host/target - so then after a while, locks get refreshed, and session timeout hits - first lock -> no prob, ne_auth.c:ah_post_send() has auth_challenge() failing, returning error, which puts that lock into m_aRemoveDeferred list - _but_ ah_post_send() then does a clean_session(), and the next lock refresh from the same session hits NULLPTR session host -> so let's delay any sspi_host cleanup until session object gets freed, instead of just cleaned Change-Id: Ie257310c47913aef9fcfec92c1722d64b28c4f89 Reviewed-on: https://gerrit.libreoffice.org/85614 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-12-12Enable -Wdeprecated-copy-dtor where availableStephan Bergmann103-0/+103
We already get -Wdeprecated-copy (warning about implicitly defined copy functions that will in the future be deleted because other user-provided copy functions exist) automatically through -Wextra, where available. -Wdeprecated-copy-dtor (warning about implicitly defined copy functions that will in the future be deleted because of a user-provided dtor) is split off into its own warning excluded from -Wextra for somewhat unclear reasons, see the discussion at <https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=88136> "-Wdeprecated-copy is draconian and shouldn't be in -Wall". But -Wdeprecated-copy-dtor has been useful in finding issues (esp. the Clang 10 trunk version, which, unlike the GCC 9 version, also finds copy functions that are implicitly defined because they are used from template instantiations), see 3e59716375a240576fd6d8759b32b4319506ed70 "Prevent BroadcastRecalcOnRefMoveHandler copies" and 4f98cd0f9ce9c2a331a5d34b3ef9d18f9bb6b235 "ScShapeChild has broken copy functions". We need to disable -Wdeprecated-copy-dtor in files included from external/boost, and in two compilerplugin/clang/test/ files. Change-Id: I74b159c3a046e23661473ddbfe53c92c4136a9db Reviewed-on: https://gerrit.libreoffice.org/85073 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-12external/skia: Further -Werror=deprecated-copy-dtor for Clang 10 trunkStephan Bergmann1-0/+10
...where the warning finds more occurrences than with GCC Change-Id: I12303de8f3b2d3299e847480e556ad03663d5401 Reviewed-on: https://gerrit.libreoffice.org/85040 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-12update Skia to chrome/m80Luboš Luňák9-299/+309
Change-Id: I26782c8bd3d8ce34cbf7ce5a00b884436d37cb85 Reviewed-on: https://gerrit.libreoffice.org/84617 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-12-04external/icu: Fix -Werror=deprecated-copy-dtorStephan Bergmann2-0/+26
...happening when LO code includes skia files: > In file included from workdir/UnpackedTarball/icu/source/i18n/unicode/format.h:47, > from workdir/UnpackedTarball/icu/source/i18n/unicode/numfmt.h:39, > from i18nutil/source/utility/unicode.cxx:26: > workdir/UnpackedTarball/icu/source/i18n/unicode/fieldpos.h: In copy constructor ‘icu_65::FieldPosition::FieldPosition(const icu_65::FieldPosition&)’: > workdir/UnpackedTarball/icu/source/i18n/unicode/fieldpos.h:146:102: error: implicitly-declared ‘constexpr icu_65::UObject::UObject(const icu_65::UObject&)’ is deprecated [-Werror=deprecated-copy-dtor] > 146 | : UObject(copy), fField(copy.fField), fBeginIndex(copy.fBeginIndex), fEndIndex(copy.fEndIndex) {} > | ^ > In file included from workdir/UnpackedTarball/icu/source/common/unicode/bytestream.h:44, > from workdir/UnpackedTarball/icu/source/common/unicode/locid.h:38, > from include/i18nlangtag/languagetagicu.hxx:16, > from i18nutil/source/utility/unicode.cxx:23: > /data/sbergman/lo-gcc/core/workdir/UnpackedTarball/icu/source/common/unicode/uobject.h:230:13: note: because ‘icu_65::UObject’ has user-provided ‘virtual icu_65::UObject::~UObject()’ > 230 | virtual ~UObject(); > | ^ See e9e4eb0736d5582fa37dcad20bf5826c50029249 "Fix some -Werror=deprecated-copy-dtor" for details about -Wdeprecated-copy-dtor. Change-Id: I89b94047af30452dd4e316b33877dd0775a851aa Reviewed-on: https://gerrit.libreoffice.org/84426 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-04external/skia: Fix -Werror=deprecated-copy-dtorStephan Bergmann2-0/+12
...happening when LO code includes skia files: > vcl/skia/gdiimpl.cxx: In member function ‘void SkiaSalGraphicsImpl::createOffscreenSurface()’: > vcl/skia/gdiimpl.cxx:246:83: error: implicitly-declared ‘sk_app::VulkanWindowContext::SharedGrContext& sk_app::VulkanWindowContext::SharedGrContext::operator=(const sk_app::VulkanWindowContext::SharedGrContext&)’ is deprecated [-Werror=deprecated-copy-dtor] > 246 | mOffscreenGrContext = sk_app::VulkanWindowContext::getSharedGrContext(); > | ^ > In file included from vcl/inc/skia/gdiimpl.hxx:29, > from vcl/skia/gdiimpl.cxx:20: > workdir/UnpackedTarball/skia/tools/sk_app/VulkanWindowContext.h:35:9: note: because ‘sk_app::VulkanWindowContext::SharedGrContext’ has user-provided ‘sk_app::VulkanWindowContext::SharedGrContext::~SharedGrContext()’ > 35 | ~SharedGrContext() { shared.reset(); checkDestroyShared(); } > | ^ See e9e4eb0736d5582fa37dcad20bf5826c50029249 "Fix some -Werror=deprecated-copy-dtor" for details about -Wdeprecated-copy-dtor. Change-Id: Ic393acff5c4d8e3eaa78b4dfed51626f73e95ed4 Reviewed-on: https://gerrit.libreoffice.org/84425 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-04nss: Fix Android build for x86 and x86_64Michael Weghorn1-4/+8
... which previously failed with cd freebl; make libs error: unknown target CPU 'armv8-a' and cd freebl; make libs error: unknown target CPU 'armv8-a+crypto' respectively. Change-Id: Ib8a6bfc615c4fb15a1e5dd3e55bba187ff34a891 Reviewed-on: https://gerrit.libreoffice.org/84369 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-12-03external/clucene: Adapt to C++20 deleted ostream << for non-plain char typesStephan Bergmann2-0/+30
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html> "char8_t backward compatibility remediation", as implemented now by <https://gcc.gnu.org/ git/?p=gcc.git;a=commit;h=0c5b35933e5b150df0ab487efb2f11ef5685f713> "libstdc++: P1423R3 char8_t remediation (2/4)" for -std=c++2a, deletes operator << overloads that would print a pointer rather than a (presumably expected) string. So this infoStream output appears to have always been broken (the strings use TCHAR, which appears to unconditionally be a typedef for wchar_t, see workdir/UnpackedTarball/clucene/src/shared/CLucene/clucene-config.h), and appears to be just of informative nature, so just simplify it to not try to print any problematic parts. Change-Id: Ie9f8edb03aff461a15718a0c025af57004aba0a9 Reviewed-on: https://gerrit.libreoffice.org/84320 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-03split instrinsics CXXFLAGS per each instruction setLuboš Luňák1-15/+28
The common usage pattern should be having one source file per each instruction set and then one source file compiled with neutral flags that dispatches to the relevant code based on runtime checks. Which means that there can't be any one "correct" flag, otherwise all files would get compiled e.g. with SSE4.2 but then CPUs capable only of SSE2 would crash running that code. Change-Id: I362bf66f672dae4588a48effe3bcd30c34ea75b3 Reviewed-on: https://gerrit.libreoffice.org/84227 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-12-02android: Fix nss build on aarch64.Jan Holesovsky2-3/+20
Change-Id: I51c03e13fba4619a881ade27d149722698859815 Reviewed-on: https://gerrit.libreoffice.org/81888 Tested-by: Jenkins Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2019-12-02android: Add also aarch64 to avoid linking errors.Jan Holesovsky1-1/+1
Change-Id: Ifdd696dc37de541bc722807054cd4ba7b862c175 Reviewed-on: https://gerrit.libreoffice.org/81904 Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com> (cherry picked from commit 620f39b816e3f10a4e047bb4f5ed5f4fdad2b364) Reviewed-on: https://gerrit.libreoffice.org/81914
2019-11-29do not explicitly link to libGLXLuboš Luňák1-1/+0
Apparently it doesn't exist on some old distros, and libGL links to libGLX anyway. Change-Id: I71ed5aef9e2309b34f9fed6fd1825c1cdb6b1afb
2019-11-27android: Introduce --enable-android-lok configure switch to fix RGB vs. BGR.Jan Holesovsky1-1/+2
This indicates that the build targets the Online-based Android app, for which we need to avoid various tweaks that are needed for the 'old' Android app present in the android/ subdir of core.git. In particular, the switch used in this patch fixes a RGBA vs. BGRA confusion that caused yellow <-> cyan switch in the Online-based Android app. Change-Id: I5f394868f51ce87013677834cfafb967b9bb333e Reviewed-on: https://gerrit.libreoffice.org/83342 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Jan Holesovsky <kendy@collabora.com> (cherry picked from commit 49002a143a4534df5f6139e07fefd06174621c59) Reviewed-on: https://gerrit.libreoffice.org/83718 Tested-by: Jenkins
2019-11-27external/skia: -Werror,-Wdeprecated-copyStephan Bergmann2-0/+25
> In file included from vcl/skia/gdiimpl.cxx:20: > In file included from vcl/inc/skia/gdiimpl.hxx:28: > In file included from workdir/UnpackedTarball/skia/include/core/SkSurface.h:13: > workdir/UnpackedTarball/skia/include/core/SkSurfaceProps.h:66:5: error: definition of implicit copy assignment operator for 'SkSurfaceProps' is deprecated because it has a user-declared copy constructor [-Werror,-Wdeprecated-copy] > SkSurfaceProps(const SkSurfaceProps& other); > ^ > workdir/UnpackedTarball/skia/tools/sk_app/DisplayParams.h:16:8: note: in implicit copy assignment operator for 'SkSurfaceProps' first required here > struct DisplayParams { > ^ > workdir/UnpackedTarball/skia/tools/sk_app/VulkanWindowContext.h:57:24: note: in implicit copy assignment operator for 'sk_app::DisplayParams' first required here > fDisplayParams = params; > ^ with recent Clang 10 trunk, similar to ae71a0adef64b292ab01194817d2d763f7c85433 "Remove some redundantly user-declared copy ctors and assignment ops" Change-Id: I71263d8b3725478afc3a72f6f3ee9d73a277a8fd Reviewed-on: https://gerrit.libreoffice.org/83907 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Michael Stahl <michael.stahl@cib.de>
2019-11-27external/skia: C++20 comparison operator fixStephan Bergmann2-1/+21
Missing const leads to overload resolution ambiguity when a synthesized candidate of operator == for a reversed-argument rewrite conflicts with the actual operator ==, due to the asymmetric const-ness of the implicit object parameter and the RHS parameter: > In file included from workdir/UnpackedTarball/skia/src/shaders/SkLightingShader.cpp:15: > In file included from workdir/UnpackedTarball/skia/src/core/SkReadBuffer.h:13: > In file included from workdir/UnpackedTarball/skia/include/core/SkFont.h:13: > In file included from workdir/UnpackedTarball/skia/include/core/SkTypeface.h:16: > In file included from workdir/UnpackedTarball/skia/include/core/SkString.h:15: > workdir/UnpackedTarball/skia/include/private/SkTArray.h:389:35: error: use of overloaded operator '!=' is ambiguous (with operand types 'SkLights::Light' and 'SkLights::Light') > if (fItemArray[index] != right.fItemArray[index]) { > ~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~ > workdir/UnpackedTarball/skia/src/shaders/SkLightingShader.cpp:268:35: note: in instantiation of member function 'SkTArray<SkLights::Light, false>::operator==' requested here > return fDirectionalLights == lightingFP.fDirectionalLights && > ^ > workdir/UnpackedTarball/skia/src/shaders/SkLights.h:90:14: note: candidate function > bool operator!=(const Light& other) { return !(this->operator==(other)); } > ^ > workdir/UnpackedTarball/skia/src/shaders/SkLights.h:83:14: note: candidate function > bool operator==(const Light& other) { > ^ > workdir/UnpackedTarball/skia/src/shaders/SkLights.h:83:14: note: candidate function (with reversed parameter order) Change-Id: I61b28e191b36f84df6920b4143809d1f497b9113 Reviewed-on: https://gerrit.libreoffice.org/83900 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Michael Stahl <michael.stahl@cib.de>
2019-11-27external/liblangtag: Avoid null pointer deref in lt_warning callStephan Bergmann2-0/+20
Recent GCC 10 trunk warns (when LO is configured with --enable-optimized): > In file included from lt-script-db.c:24: > lt-script-db.c: In function ‘lt_script_db_parse.constprop’: > lt-messages.h:105:2: error: ‘%s’ directive argument is null [-Werror=format-overflow=] > 105 | lt_message_printf(LT_MSG_WARNING, \ > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 106 | LT_MSG_FLAG_NONE, \ > | ~~~~~~~~~~~~~~~~~~~ > 107 | 0, \ > | ~~~~~~ > 108 | __VA_ARGS__) > | ~~~~~~~~~~~~ > lt-script-db.c:137:4: note: in expansion of macro ‘lt_warning’ > 137 | lt_warning("No subtag node: description = '%s'", > | ^~~~~~~~~~ > lt-script-db.c:137:47: note: format string is defined here > 137 | lt_warning("No subtag node: description = '%s'", > | ^~ Change-Id: I2924f7aab84f4f2640f277ee5c2689753627ae78 Reviewed-on: https://gerrit.libreoffice.org/83869 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-27do not require Vulkan devel package for SkiaLuboš Luňák2-0/+14
I don't see why this should use libvulkan.so, using libvulkan.so.1 should do as well, and quite possibly any future libvulkan.so.2 could be binary-incompatible anyway. Change-Id: I46be40da7fbfdcb59c947e6d088820e580cf4c44
2019-11-27patch Skia bug with copying data with different alpha typeLuboš Luňák2-0/+14
https://bugs.chromium.org/p/skia/issues/detail?id=9662 Change-Id: Ic5208c2c817912cddbfae4b86e3b3647306262fb
2019-11-27fix Skia with --enable-pch=fullLuboš Luňák1-0/+28
Change-Id: I6bec47e373c042d1ffb3607bf5dca9dfe2509466
2019-11-27solve the Skia lerp() conflict differentlyLuboš Luňák1-8/+6
New versions of libstdc++ provide lerp() in the global namespace, older ones don't, but it depends on the libstdc++ version and not the c++ version. Since the function is local, just "rename" it. Change-Id: I37896190c620350739fba9b8ce6544f945519244
2019-11-27disable Skia resource leak checking on exitLuboš Luňák2-0/+27
This is normally enabled in Skia debug builds and it asserts if there is a problem, which there is with a number of our unittests that leak something (usually a VirtualDevice). Those are non-trivial to find and don't matter in practice (or if they do they should be fixed for all VCL backends), so just disable the Skia check. Change-Id: I0a0721d8a3f0f961e14513574f4b3cc88ec1e62c
2019-11-27make Skia GPU offscreen surfaces work with unittestsLuboš Luňák3-173/+189
Skia is now patched to be able to create also invalid sk_app::WindowContext that will just initialize the shared GrContext. And always use that GrContext, even for tests, because some tests first create a offscreen surfaces and only later create windows, which before this patch led to mixing GrContext instances. Change-Id: Ic79c0719f98f6ac48527c2ea2a9a9a69412adeff
2019-11-27make Skia VCL backend fall back to raster if vulkan doesn't workLuboš Luňák1-1/+1
Change-Id: Ic446f6f85e5ebc2e50cb51a3ed1e732b8976a193
2019-11-27fix Skia offscreen GPU-backed drawingLuboš Luňák3-1/+512
The previous approach of using multiple GrContext instances apparently does not work, it's not possible to do drawing operations that involve objects using two different GrContext's. So patch Skia to use just one GrContext for our needs. See vcl/skia/README for details. Change-Id: I2bd3d3c618bf7f8ff45b2f37cbd086d2289940aa
2019-11-27make SkiaSalGraphicsImpl use GPU-backed SkSurface also for offscreenLuboš Luňák2-0/+35
Skia's sk_app::WindowContext can create GPU-backed SkSurface only for windows, but we also use virtual devices that are not windows. Fortunately, SkSurface can be created GPU-backed from GrContext* and sk_gpu_test::GrContextFactory seems to provide it easily. It is not completely clear to me what the rules are on mixing SkSurface's with different GrContext* (see the comment in SkiaSalGraphicsImpl::copyBits()), but it seems to work fine. Change-Id: I8110b67c41ab092e0c4b6a0973d6bed8a408c4c1
2019-11-27update Skia fix-shader-locale.patch.1 to the upstream versionLuboš Luňák1-56/+39
Change-Id: Ie8606f30d3f821d7b195aa7978886d529a57bfd2
2019-11-27update Skia PCH after the update to m79Luboš Luňák2-23/+43
Change-Id: I1e18686ac6f501a04d6f56c78c998621d430d721
2019-11-27fix Skia/vulkan with some localesLuboš Luňák2-1/+58
Change-Id: Ie2dcd526efba5631a6956023d864be828c6eb634
2019-11-27update Skia to chrome-m79Luboš Luňák5-54/+80
Change-Id: Ie79f4752c4d0978b816774674bc923e6973289f8
2019-11-27update PCH for SkiaLuboš Luňák1-5/+19
Change-Id: Iece4d90774890576bd3d84ed2218de56def96077
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-28 00:39:26 +0000