summaryrefslogtreecommitdiff
path: root/external
AgeCommit message (Collapse)Author
2024-04-24use --binary flag when applying patches with patch from git-bashChristian Lohmaier
Change-Id: Idbd4ad7ad89dc727e2f0cf851c4c62f05d5b2a0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166328 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-04-23external/icu: Drop hidden dependency on PythonStephan Bergmann
...which was always satisfied directly from the system, regardless of our --enable-python=... setting. (And which was a problem for my Git Bash and WSL based Windows build attempt, where it happened to find a dysfunctional Python wrapper at C:/Users/steph/AppData/Local/Microsoft/WindowsApps/python3 which caused a [...] > Not rebuilding data/rules.mk, assuming prebuilt data in data/in > Spawning Python to generate test/testdata/rules.mk... > Python was not found; run without arguments to install from the Microsoft Store, or disable this shortcut from Settings > Manage App Execution Aliases. > configure: error: Python failed to run; see above error. error when building ExternalProject_icu.) There are three uses of that PYTHON setting across workdir/UnpackedTarget/icu: 1 In source/configure.ac to generate source/data/rules.mk if source/data/locales/root.txt would exist---but which doesn't, so we don't actually need PYTHON there. 2 In source/configure.ac to generate source/test/testdata/rules.mk, but which our (non-check) build apparently doesn't need anyway. 3 In source/data/Makefile.in for target check-local, which is a sub-target of check (which we don't build). Change-Id: I7455cc91fc67f36582bf54851c07030830cd3b8d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166500 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-04-22tdf#150082: LO Base MariaDB/MySQL connector don't accept auth via gssapiJulien Nabet
Exclude Windows since we're not sure gssapi.h is available (at least Jenkins Windows machine doesn't have it) Change-Id: Iba396f77b07dce4291de5eb0e6ad7c0c25e6c3c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159954 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-04-22Update pdfium to 6425Miklos Vajna
Drop parts of build.patch.1 and the entire include.patch, which are probably obsolete and don't apply anymore. Change-Id: I18c8d5e2ee97c7793e75ac0e47b5705b99585d59 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166415 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-04-22REAL_CC[_CFLAGS] are already set by gb_ExternalProject_runChristian Lohmaier
(and that also takes care of proper quoting) Change-Id: Ic8c29300a2e6d5381c0d8873572f7c076362c93d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166324 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-04-18external/argon2: Adapt vcxproj to Debug|ARM64Stephan Bergmann
Change-Id: I3a881c56859d5db36ee13a63aec6926d0e3f2638 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166230 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-18libwebp: Upgrade to 1.4.0Xisco Fauli
Change-Id: I196316b0c7efbe27c06b8dfed90db5248db6dce4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166185 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-04-15Update libxmlsec to 1.3.4Miklos Vajna
Allows dropping xmlsec-nss-Ensure-NSS-algorithms-are-initialized-754.patch.1, which was a backport. Change-Id: Ifdd0b5285daa79116a91ab2d122a9809f8effb5e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166019 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-04-08clean up after removal of patched rhinoRene Engelhard
Change-Id: I193fd0c10d297555faa7a832718dbd6cd929a406 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165762 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-07Upgrade external/boost to latest Boost 1.84.0Stephan Bergmann
<https://dev-www.libreoffice.org/src/boost_1_84_0.tar.xz> has been generated (on Fedora 39) with > $ wget https://boostorg.jfrog.io/artifactory/main/release/1.84.0/source/boost_1_84_0.tar.bz2 > $ printf 'cc4b893acf645c9d4b698e9a0f08ca8846aa5d6c68275c14c3e7949c24109454 boost_1_84_0.tar.bz2' | sha256sum -c # cf. <https://www.boost.org/users/history/version_1_84_0.html> > boost_1_84_0.tar.bz2: OK > $ external/boost/repack_tarball.sh boost_1_84_0.tar.bz2 > Unpacking boost_1_84_0.tar.bz2 ... > Removing unnecessary files ... > Creating boost_1_84_0.tar.xz ... > Cleaning up ... > fd4a2ee785ea0e4efc5221a4284e0cf51096e8409871fb70fdaced002eeffc0b boost_1_84_0.tar.xz > Done. * external/boost/0001-Avoid-boost-phoenix-placeholders-uarg1.10-ODR-violat.patch.2 was obsoleted by <https://github.com/boostorg/phoenix/commit/665047aac26ad4d96b266d87504b3a88ad21b37e> "avoid ODR by making this const". * The modified external/boost/windows-no-utf8-locales.patch.0, whose original version no longer applied as-is, should hopefully still mitigate the issue described in 072a25e1ef4815bbef4f18f59f025862a0d8e876 "tdf#157135 workaround: restore and update windows-no-utf8-locales.patch.0". * external/boost/Wundef.patch.0 is needed to silence > In file included from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/boost/boost/throw_exception.hpp:24, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/boost/boost/unordered/detail/serialize_tracked_address.hpp:16, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/boost/boost/unordered/detail/fca.hpp:117, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/boost/boost/unordered/detail/implementation.hpp:17, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/boost/boost/unordered/detail/map.hpp:7, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/boost/boost/unordered/unordered_map.hpp:17, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/boost/boost/unordered_map.hpp:17, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/external/boost/include/boost/unordered_map.hpp:30, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/configmgr/source/modifications.hxx:28, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/configmgr/source/data.hxx:34, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/configmgr/source/groupnode.cxx:26: > /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/boost/boost/unordered/detail/type_traits.hpp:51:22: error: "BOOST_LIBSTDCXX_VERSION_WORKAROUND_GUARD" is not defined, evaluates to 0 [-Werror=undef] > 51 | #if BOOST_WORKAROUND(BOOST_LIBSTDCXX_VERSION, < 50000) > | ^~~~~~~~~~~~~~~~~~~~~~~ > /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/boost/boost/config/workaround.hpp:272:10: note: in definition of macro ‘BOOST_WORKAROUND’ > 272 | ((symbol ## _WORKAROUND_GUARD + 0 == 0) && \ > | ^~~~~~ > /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/boost/boost/unordered/detail/type_traits.hpp:64:22: error: "BOOST_LIBSTDCXX_VERSION_WORKAROUND_GUARD" is not defined, evaluates to 0 [-Werror=undef] > 64 | #if BOOST_WORKAROUND(BOOST_LIBSTDCXX_VERSION, < 50000) > | ^~~~~~~~~~~~~~~~~~~~~~~ > /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/boost/boost/config/workaround.hpp:272:10: note: in definition of macro ‘BOOST_WORKAROUND’ > 272 | ((symbol ## _WORKAROUND_GUARD + 0 == 0) && \ > | ^~~~~~ > /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/boost/boost/unordered/detail/type_traits.hpp:77:22: error: "BOOST_LIBSTDCXX_VERSION_WORKAROUND_GUARD" is not defined, evaluates to 0 [-Werror=undef] > 77 | #if BOOST_WORKAROUND(BOOST_LIBSTDCXX_VERSION, < 50000) > | ^~~~~~~~~~~~~~~~~~~~~~~ > /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/boost/boost/config/workaround.hpp:272:10: note: in definition of macro ‘BOOST_WORKAROUND’ > 272 | ((symbol ## _WORKAROUND_GUARD + 0 == 0) && \ > | ^~~~~~ etc. (<https://ci.libreoffice.org/job/gerrit_linux_gcc_release/155922/>) as seen with some versions of GCC which apparently fail to honor in that situation the > #pragma GCC diagnostic ignored "-Wundef" in the external/boost/include wrappers. (Using > #pragma GCC system_header in those external/boost/include wrappers had been dismissed with 29661a886e4157e0cb6141b49fb5602fa621cc9a "boost: stop using #pragma GCC system_header".) Change-Id: Idf1d5a17bc198b8ea7a54751e8e2fa6ca2169167 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161138 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-03external/lxml: Silence -Wincompatible-pointer-typesStephan Bergmann
...as seen with recent GCC 14 trunk, > gcc -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -g -O0 -Wall -I/home/sberg/lo/core/workdir/UnpackedTarball/zlib -I/home/sberg/lo/core/workdir/UnpackedTarball/python3 -I/home/sberg/lo/core/workdir/UnpackedTarball/python3/Include -fPIC -DCYTHON_CLINE_IN_TRACEBACK=0 -I/home/sberg/lo/core/workdir/UnpackedTarball/libxml2/include -I/home/sberg/lo/core/workdir/UnpackedTarball/libxslt -Isrc -Isrc/lxml/includes -I/home/sberg/lo/core/workdir/UnpackedTarball/python3/Include -I/home/sberg/lo/core/workdir/UnpackedTarball/python3 -c src/lxml/etree.c -o build/temp.linux-x86_64-3.8-pydebug/src/lxml/etree.o -w > src/lxml/etree.c: In function ‘__pyx_pf_4lxml_5etree_11TreeBuilder_4data’: > src/lxml/etree.c:137698:66: error: passing argument 1 of ‘__pyx_f_4lxml_5etree_11TreeBuilder__handleSaxData’ from incompatible pointer type [-Wincompatible-pointer-types] > 137698 | __pyx_t_1 = __pyx_f_4lxml_5etree_11TreeBuilder__handleSaxData(((struct __pyx_obj_4lxml_5etree__SaxParserTarget *)__pyx_v_self), __pyx_v_data); if (unlikely(__pyx_t_1 == ((int)-1))) __PYX_ERR(3, 832, __pyx_L1_error) > | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > | | > | struct __pyx_obj_4lxml_5etree__SaxParserTarget * > src/lxml/etree.c:137074:105: note: expected ‘struct __pyx_obj_4lxml_5etree_TreeBuilder *’ but argument is of type ‘struct __pyx_obj_4lxml_5etree__SaxParserTarget *’ > 137074 | static int __pyx_f_4lxml_5etree_11TreeBuilder__handleSaxData(struct __pyx_obj_4lxml_5etree_TreeBuilder *__pyx_v_self, PyObject *__pyx_v_data) { > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~ etc. Change-Id: I19f6768bf031c04730972c1fa4a006e2a7d50e27 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165758 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-02Update to latest Rhino 1.7.14Stephan Bergmann
...at the expense of losing, at least for now, the script editor for it (which had been hacked into the old upstream sources in a hard-to-maintain way). rhino-1.7.14.zip is taken from <https://github.com/mozilla/rhino/releases/download/Rhino1_7_14_Release/rhino-1.7.14.zip>. Building it would now use Gradle, but instead just hack together an invocation of javac and jar in external/rhino/ExternalProject_rhino.mk that effectively generates the same jar as the upstream-built jar available at <https://github.com/mozilla/rhino/releases/download/Rhino1_7_14_Release/rhino-1.7.14.jar>. All the various patches are no longer necessary: * external/rhino/rhino1_5R5.patch and external/rhino/OfficeScriptInfo.java were mostly for the hacked-in script editor, which has been abandoned at least for now (see above). * external/rhino/rhino1_5R5-find_swing.patch (originally from 0a7f9346503a557f583bced269655fa1996550af "ause109: #i106296# make build.xml aware of TARFILE_LOCATION") appears to be obsolete. * external/rhino/rhino1_5R5-updateToolTip.patch is covered by <https://github.com/mozilla/rhino/commit/ab20a73b16f68daf715c7ac4808c119bb15d698c> "Fix bug 414869: Rhino debugger fails to launch due to updates in mac os x leopard". * external/rhino/rhino-classpath.patch.1 from bb58293296f843654045d7b0eba6899d11533a4a "rhino: unbreak build on Fedora 34" was only relevant when building with Ant. Change-Id: I5fca5915d785716f7aaf313ff2469a20f55f707a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165190 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-01lcms2: upgrade to 2.16Taichi Haradaguchi
* backport 0001-Added-missing-export.patch to fix the Windows build. * drop c++17.patch.1, which fixed uptream. Change-Id: Ib658ba3067c35ca5cd1ccb7b3f0f2f3bc9f82a43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165350 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-03-28libgpg-error: upgrade to release 1.48Xisco Fauli
Change-Id: I3920d10657a91b56f484a5a61017d2e2ba3291b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165457 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-03-28libassuan: upgrade to 2.5.7Xisco Fauli
Change-Id: I6114c7a77395f14e83d2315ac6f9b6829ddb1c6a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165456 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-03-28python exits on initialization if fd 0 is a dirCaolán McNamara
which can happen if stdin was closed and the next open was of a dir. Later python checks for is_valid_fd, but an invalid fd is not fatal for stdin, etc and it just return an empty stdin wrapper, so move this check lower and do the same for a dir. Change-Id: Iaf8a48927b49408577ae7a781dfc6e0255a940cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165327 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-03-26poppler: upgrade to release 24.03.0Xisco Fauli
Change-Id: Icd063dcc9a034e88283ddf16be64091a32f3453f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165292 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-03-22Clean up path in diff header linePatrick Luby
Change-Id: I181c8c0f41bd4367c622352797f4c493e16c02c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165165 Tested-by: Jenkins Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
2024-03-22Expat: upgrade to release 2.6.2Taichi Haradaguchi
Fixes CVE-2024-28757 Change-Id: Id85044fa9d8eda922425e580e9d6979f6563e98a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165129 Tested-by: Taichi Haradaguchi <20001722@ymail.ne.jp> Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-03-21tdf#152524 fix crash by skipping second fork()Patrick Luby
Instead of calling a second fork() in the child process, replace execv() with posix_spawn(). posix_spawn() does not call any atfork handlers so the atfork handler that crashes will be skipped. Change-Id: Iffb70fe4f51b6b324f13e4ac24b740da0a25da99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165103 Tested-by: Jenkins Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
2024-03-16tdf#160036 Enable SKSL when using Skia/RasterPatrick Luby
Starting with the upgrade of Skia from m111 to m116, SKSL is disabled by default for Skia/Raster so define SK_RASTER_PIPELINE_OPS_ALL to enable it. Also, reenable XOR drawing unit tests that were previously failing. Change-Id: Ibd10efa0540f1e87123c341b529c8e3931e1a8fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164933 Tested-by: Jenkins Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
2024-03-16Revert "make skia into static library"Noel Grandin
This reverts commit 806b6014db796a3970332f9cefaaabf9355d0d8f. Reverting for now, this does not work with --enable-mergelib Change-Id: Ib44f819d0da9ed3769f76fc40b5c15ce097390a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164872 Tested-by: René Engelhard <rene@debian.org> Reviewed-by: René Engelhard <rene@debian.org>
2024-03-16make skia into static libraryNoel Grandin
We only need it inside one library, and this reduces the symbols we export from libmerged by over 1000. Change-Id: I8bf1b2479ba61e931dab0a5cfa81484d534c5658 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164846 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-08external/skia: Fix a std::sort comparison function's assertion assumptionsStephan Bergmann
At least with a LLVM 19 libc++ in hardening debug mode (where it uses additional invocations of the comparison function passed to std::sort, to verify that the function actually implements a strict weak ordering), chart2_dialogs_test failed with > LO_TEST_LOCALE=en-US > [_RUN_____] Chart2DialogsTest::openAnyDialog > workdir/UnpackedTarball/skia/src/sksl/transform/SkSLFindAndDeclareBuiltinVariables.cpp:112: fatal error: "assert(InterfaceBlockName(*a) != InterfaceBlockName(*b))" apparently because the implementation of std::sort made additional same-arguments calls of operator ()(x, x) that the Skia implementation of the comparison function was not expecting to happen. But the only relevant guarantee that C++20 appears to make for std::sort is that its complexity is O(N log N) comparisons, so any implementation could legitimately do such a "useless" additional same-arguments call of operator ()(x, x) for each of the N elements of the to-be-sorted range. Change-Id: I3a14eb05b5ae9101f37f92e10ecc91a90585de87 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164577 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-29tdf#113050 poppler: Enable splashDr. David Alan Gilbert
Enable the splash module, to be used in the xpdf conversion for tiled patterns. I've jumped through a couple of hoops to avoid splash bringing in freetype, extending the existing hack. This might cause us problems if someone tries to use text as a tile, but otherwise isOK. Change-Id: I76ad1268f44137ae5e3205d56170c3a7c55a2dc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163560 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-28tdf#157135 workaround: restore and update windows-no-utf8-locales.patch.0Mike Kaganski
This partially reverts commit ed259e5efe432386b54c553cbc644b3b64976852 (Upgrade external/boost to latest Boost 1.81.0, 2023-01-05), which had dropped the patch previously introduced with commit f046fed2782f0d4244aff719ba70a56399a2583a (Don't ever attempt to initialise a std::locale with a UTF-8 locale on Windows, 2018-05-17). It seems that there is a nightmare going on in MSVCRT, and tdf#157135 is caused by dome MS bug. The problem happens in a deeply nested call to mbstowcs_s (several levels deep from std::locale constructor with name of "en_US.UTF-8"), which gets a non-null wcstr and sizeInWords equal to zero, which generates an invalid argument handler, resulting in a failed assertion "(pwcs == nullptr && sizeInWords == 0) || (pwcs != nullptr && sizeInWords > 0)" in _mbstowcs_internal from minkernel\crts\ucrt\src\appcrt\convert\mbstowcs.cpp:245, and a crash. The crashreporter initiates, but since it tries to use CRT itself, which is in fastfail mode, it hangs. The patch that is restored here was intended for something different; but it happily workarounds the nightmare. Until the proper fix found, let it be. Change-Id: Ic978f87e2e7b81fc2e1cd182a4247084ad016a9f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164068 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-27GPGME: upgrade to release 1.23.2Taichi Haradaguchi
Change-Id: I56c419fbbe615ef57b7d8117ccdc32f0daddf95f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163840 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-02-26external/freetype: nullptr-with-offsetStephan Bergmann
...as seen during CppunitTest_xmloff_style, > workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:1048:31: runtime error: applying zero offset to null pointer > #0 in tt_var_get_item_delta at workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:1048:31 > #1 in tt_hvadvance_adjust at workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:1242:13 > #2 in tt_vadvance_adjust at workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:1278:12 > #3 in tt_face_get_metrics at workdir/UnpackedTarball/freetype/src/sfnt/ttmtx.c:319:11 > #4 in cff_slot_load at workdir/UnpackedTarball/freetype/src/cff/cffgload.c:660:11 > #5 in cff_glyph_load at workdir/UnpackedTarball/freetype/src/cff/cffdrivr.c:192:13 > #6 in FT_Load_Glyph at workdir/UnpackedTarball/freetype/src/base/ftobjs.c:1066:15 > #7 in _cairo_ft_scaled_glyph_load_glyph at workdir/UnpackedTarball/cairo/src/cairo-ft-font.c:2455:13 > #8 in _cairo_ft_scaled_glyph_init at workdir/UnpackedTarball/cairo/src/cairo-ft-font.c:2640:11 > #9 in _cairo_scaled_glyph_lookup at workdir/UnpackedTarball/cairo/src/cairo-scaled-font.c:3035:6 > #10 in _cairo_scaled_font_glyph_device_extents at workdir/UnpackedTarball/cairo/src/cairo-scaled-font.c:2250:15 > #11 in _cairo_composite_rectangles_init_for_glyphs at workdir/UnpackedTarball/cairo/src/cairo-composite-rectangles.c:476:14 > #12 in _cairo_compositor_glyphs at workdir/UnpackedTarball/cairo/src/cairo-compositor.c:280:14 > #13 in _cairo_image_surface_glyphs at workdir/UnpackedTarball/cairo/src/cairo-image-surface.c:1030:12 > #14 in _cairo_surface_show_text_glyphs at workdir/UnpackedTarball/cairo/src/cairo-surface.c:2920:15 > #15 in _cairo_gstate_show_text_glyphs at workdir/UnpackedTarball/cairo/src/cairo-gstate.c:2077:15 > #16 in _cairo_default_context_glyphs at workdir/UnpackedTarball/cairo/src/cairo-default-context.c:1334:12 > #17 in cairo_show_glyphs at workdir/UnpackedTarball/cairo/src/cairo.c:3670:14 > #18 in CairoTextRender::DrawTextLayout(GenericSalLayout const&, SalGraphics const&) at vcl/unx/generic/gdi/cairotextrender.cxx:477:9 > #19 in SvpSalGraphics::DrawTextLayout(GenericSalLayout const&) at vcl/headless/svptext.cxx:72:23 > #20 in GenericSalLayout::DrawText(SalGraphics&) const at vcl/source/gdi/CommonSalLayout.cxx:171:18 > #21 in OutputDevice::ImplDrawTextDirect(SalLayout&, bool) at vcl/source/outdev/text.cxx:312:16 > #22 in OutputDevice::ImplDrawText(SalLayout&) at vcl/source/outdev/text.cxx:463:9 > #23 in OutputDevice::DrawTextArray(Point const&, rtl::OUString const&, KernArraySpan, std::span<unsigned char const, 18446744073709551615ul>, int, int, SalLayoutFlags, SalLayoutGlyphs const*) at vcl/source/outdev/text.cxx:701:9 > #24 in SwFntObj::DrawText(SwDrawTextInfo&) at sw/source/core/txtnode/fntcache.cxx:1490:31 > #25 in SwSubFont::DrawText_(SwDrawTextInfo&, bool) at sw/source/core/txtnode/swfont.cxx:1144:24 > #26 in SwFont::DrawText_(SwDrawTextInfo&) at sw/source/core/inc/swfont.hxx:324:29 > #27 in SwTextPaintInfo::DrawText_(rtl::OUString const&, SwLinePortion const&, o3tl::strong_int<int, Tag_TextFrameIndex>, o3tl::strong_int<int, Tag_TextFrameIndex>, bool, bool, bool, bool) at sw/source/core/text/inftxt.cxx:730:21 > #28 in SwTextPaintInfo::DrawText(SwLinePortion const&, o3tl::strong_int<int, Tag_TextFrameIndex>, bool) const at sw/source/core/text/inftxt.hxx:783:41 > #29 in SwTextPortion::Paint(SwTextPaintInfo const&) const at sw/source/core/text/portxt.cxx:603:18 > #30 in SwTextPainter::DrawTextLine(SwRect const&, SwSaveClip&, bool, std::optional<SwTaggedPDFHelper>&, std::optional<SwTaggedPDFHelper>&, bool) at sw/source/core/text/itrpaint.cxx:433:23 > #31 in SwTextFrame::PaintSwFrame(OutputDevice&, SwRect const&) const at sw/source/core/text/frmpaint.cxx:787:23 > #32 in SwLayoutFrame::PaintSwFrame(OutputDevice&, SwRect const&) const at sw/source/core/layout/paintfrm.cxx:3804:21 > #33 in SwFlyFrame::PaintSwFrame(OutputDevice&, SwRect const&) const at sw/source/core/layout/paintfrm.cxx:4507:20 > #34 in SwVirtFlyDrawObj::wrap_DoPaintObject(drawinglayer::geometry::ViewInformation2D const&) const at sw/source/core/draw/dflyobj.cxx:541:18 > #35 in drawinglayer::primitive2d::(anonymous namespace)::SwVirtFlyDrawObjPrimitive::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor&, drawinglayer::geometry::ViewInformation2D const&) const at sw/source/core/draw/dflyobj.cxx:244:35 > #36 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:46:24 > #37 in drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:397:13 > #38 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::Primitive2DContainer const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:69:21 > #39 in sdr::contact::ObjectContactOfPageView::DoProcessDisplay(sdr::contact::DisplayInfo&) at svx/source/sdr/contact/objectcontactofpageview.cxx:284:31 > #40 in sdr::contact::ObjectContactOfPageView::ProcessDisplay(sdr::contact::DisplayInfo&) at svx/source/sdr/contact/objectcontactofpageview.cxx:120:21 > #41 in SdrPageWindow::RedrawLayer(o3tl::strong_int<short, SdrLayerIDTag> const*, sdr::contact::ViewObjectContactRedirector*, basegfx::B2IRange const*) at svx/source/svdraw/sdrpagewindow.cxx:421:28 > #42 in SdrPageView::DrawLayer(o3tl::strong_int<short, SdrLayerIDTag>, OutputDevice*, sdr::contact::ViewObjectContactRedirector*, tools::Rectangle const&, basegfx::B2IRange const*) at svx/source/svdraw/svdpagv.cxx:265:27 > #43 in SwViewShellImp::PaintLayer(o3tl::strong_int<short, SdrLayerIDTag>, SwPageFrame const&, SwRect const&, Color const*, bool, sdr::contact::ViewObjectContactRedirector*) at sw/source/core/view/vdraw.cxx:139:20 > #44 in SwRootFrame::PaintSwFrame(OutputDevice&, SwRect const&) const at sw/source/core/layout/paintfrm.cxx:3527:33 > #45 in SwViewShell::PrtOle2(SwDoc*, SwViewOption const*, SwPrintData const&, OutputDevice&, tools::Rectangle const&, bool) at sw/source/core/view/vprint.cxx:592:27 > #46 in SwDocShell::Draw(OutputDevice*, JobSetup const&, unsigned short, bool) at sw/source/uibase/app/docsh.cxx:881:5 > #47 in SfxObjectShell::DoDraw_Impl(OutputDevice*, Point const&, Fraction const&, Fraction const&, JobSetup const&, unsigned short, bool) at sfx2/source/doc/objembed.cxx:204:5 > #48 in SfxObjectShell::DoDraw(OutputDevice*, Point const&, Size const&, JobSetup const&, unsigned short, bool) at sfx2/source/doc/objembed.cxx:151:9 > #49 in SfxObjectShell::CreatePreview_Impl(bool, VirtualDevice*, GDIMetaFile*) const at sfx2/source/doc/objcont.cxx:198:40 > #50 in SfxObjectShell::GetPreviewBitmap() const at sfx2/source/doc/objcont.cxx:110:9 > #51 in SfxObjectShell::WriteThumbnail(bool, com::sun::star::uno::Reference<com::sun::star::io::XStream> const&) at sfx2/source/doc/objstor.cxx:3850:31 > #52 in SfxObjectShell::GenerateAndStoreThumbnail(bool, com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&) at sfx2/source/doc/objstor.cxx:3808:33 > #53 in SfxObjectShell::SaveTo_Impl(SfxMedium&, SfxItemSet const*) at sfx2/source/doc/objstor.cxx:1531:19 > #54 in SfxObjectShell::PreDoSaveAs_Impl(rtl::OUString const&, rtl::OUString const&, SfxItemSet const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at sfx2/source/doc/objstor.cxx:3117:39 > #55 in SfxObjectShell::CommonSaveAs_Impl(INetURLObject const&, rtl::OUString const&, SfxItemSet&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at sfx2/source/doc/objstor.cxx:2907:9 > #56 in SfxObjectShell::APISaveAs_Impl(std::basic_string_view<char16_t, std::char_traits<char16_t>>, SfxItemSet&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at sfx2/source/doc/objserv.cxx:320:19 > #57 in SfxBaseModel::impl_store(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, bool) at sfx2/source/doc/sfxbasemodel.cxx:3233:42 > #58 in SfxBaseModel::storeToURL(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at sfx2/source/doc/sfxbasemodel.cxx:1815:13 > #59 in UnoApiTest::saveWithParams(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at test/source/unoapi_test.cxx:213:16 > #60 in UnoApiTest::save(rtl::OUString const&, char const*) at test/source/unoapi_test.cxx:178:5 > #61 in testWritingModeBTLR::TestBody() at xmloff/qa/unit/style.cxx:193:9 Change-Id: I54d4d90e203127e018b99c34785602ac3d96e425 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163925 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-25Revert "tdf#159752: Add missing NotoSans/NotoSerif fonts back"Xisco Fauli
This reverts commit aa49b95cd1bb2baa357c9aac7e5d046630ffac85. Reason for revert: https://bugs.documentfoundation.org/show_bug.cgi?id=159752#c8 Change-Id: I3f62e179240419d6cc19d9db2bf6d07673d48e05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163838 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2024-02-25tdf#124591: upgrade NotoKufiArabic to v2.109Khaled Hosny
https://github.com/notofonts/arabic/releases/tag/NotoKufiArabic-v2.109 Change-Id: Ifc6d9b6ec3e41dac27406b7582734c2cfd173a5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163878 Tested-by: خالد حسني <khaled@libreoffice.org> Reviewed-by: خالد حسني <khaled@libreoffice.org>
2024-02-23tdf#159752: Add missing NotoSans/NotoSerif fonts backXisco Fauli
They were dropped in 69943f33bf219558d6b219f0eaeda1e25e487b05 "tdf#124591: Update Noto Sans to v2.012" and 96aba2de78ffa641f6c0c898b99158715b2f2703 "tdf#124591: Update Noto Serif to v2.012" for no apparent reason. Re-add them since they are still available upstream Change-Id: Ifd5eb72bd95be96f2ff965b17846cf76aacb0c7d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163825 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-02-23Fix warning C4589 when building with MSVC without -Wv:18Mike Kaganski
Discovered by https://gerrit.libreoffice.org/c/core/+/163717 Like these: C:\libcmis\inc\libcmis/document.hxx(51): warning C4589: Constructor of abstract class 'libcmis::Document' ignores initializer for virtual base class 'libcmis::Object' C:\libcmis\inc\libcmis/document.hxx(51): note: virtual base classes are only initialized by the most-derived type C:\libcmis\inc\libcmis/folder.hxx(58): warning C4589: Constructor of abstract class 'libcmis::Folder' ignores initializer for virtual base class 'libcmis::Object' C:\libcmis\inc\libcmis/folder.hxx(58): note: virtual base classes are only initialized by the most-derived type Change-Id: Icc7f94cc02796a86b47b025df69ec3db971ad11e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163777 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-23Revert "tdf#152524 use dispatch_async() instead of dispatch_sync()"Patrick Luby
This reverts commit b0656e6ca668a0719fbcb71b6d46c68093dda470. Reason for revert: This patch has not made any positive difference for tdf#152524. Change-Id: I5ea0f80263188049f06623ac930b4dc7856dc53e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163758 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
2024-02-22tdf#159519 libxmlsec: avoid linking function not existent in Windows 7Michael Stahl
xsec_xmlsec.dll is linked to libxmlsec-mscng.dll, which is linked to Win32 bcrypt.dll, which doesn't have BCryptKeyDerivation on Windows 7. Use GetProcAddress() to retrieve BCryptKeyDerivation at runtime; the function is not used by LibreOffice. (regression from commit 26bf26272bf525b59b4a4ce18b3ce14c1febfd7b and (due to revert) commit bfd479abf0d1d8ce36c3b0dcc6c824216f88a95b) Change-Id: I0c0c94ee0cdfd48ae7506d9dfb51fcaf8289d460 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163709 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-21external/fontconfig: Adapt library nameStephan Bergmann
...to recent bbb0663813d0476b9a654207b7006315cb417c2e "Fontconfig: upgrade to release 2.15.0" Change-Id: I6abdb1889d55edc6b50beec60b5e71707695f0ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163684 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-21tdf#159529 clear hb_ot_face_t data after fetching 'sbix' and 'glyf' tablesPatrick Luby
The 'sbix' and 'glyf' tables can be very large for color emoji fonts so clear any cached data in hb_ot_face_t after fetching that table's extents. Change-Id: Id5deda9114b7199a4194ff16879e5791acd1cd82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163674 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-21Fontconfig: upgrade to release 2.15.0Taichi Haradaguchi
Change-Id: Id50d82b4dc7c3e8000b7658a9f62efa0d6b39495 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163646 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-02-19libvisio: read and use simple solid fill stylesJaume Pujantell
Implemented the reading of simple solid fills from the fill styles list in a vsdx theme. And it's use with the quick style fill matrix value. This patch includes an alternative fix to tdf#77915 so the previous patch is no longer needed. Change-Id: Iccfe915c90bcb1280cfcbfa4920d2989d18518ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163581 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com> (cherry picked from commit fb9ca6bba9bc3ce9feb9a066636dcd986dca096b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163544 Tested-by: Jenkins
2024-02-16nss: upgrade to release 3.98Michael Stahl
Fixes CVE-2023-5388 Also update README, and remove obsolete documentation of Debian's mangled SONAME; relevant Debian changelog: nss (2:3.13.4-2) unstable; urgency=low * debian/control, debian/libnss3*, debian/rules, mozilla/security/coreconf/*, mozilla/security/nss/lib/*/manifest.mn: Move to unversioned library. ABI compatibility is ensured upstream, and the SO version, if it needed a change at any time, would be a change in the library name. There is no reason to keep making compatibility more difficult with other distros and upstream binary releases. While previous versions were one-way compatible (binaries built against other distros or upstream nspr could work on Debian), this approach works both ways. -- Mike Hommey <glandium@debian.org> Thu, 17 May 2012 09:45:36 +0200 Change-Id: Ifc1eae68827fa88ae001a3903c8555af67b488ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163482 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-16tdf#159502 libxml2: apply Solaris ld patch only on SolarisMichael Stahl
Diverging from upstream by inventing a LIBXML2_GLOBAL_VARIABLES version should only be done if actually required. Change-Id: I1520ca5078dc24ffd83e927f9c857d625e71749b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163455 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-15regenerate boost headersNoel Grandin
to reduce noise when building in debug mode with gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0 e.g. In file included from /home/noel/libo2/workdir/UnpackedTarball/boost/boost/property_tree/json_parser.hpp:15, from /home/noel/libo2/external/boost/include/boost/property_tree/json_parser.hpp:30, from /home/noel/libo2/sw/inc/pch/precompiled_sw.hxx:61: /home/noel/libo2/workdir/UnpackedTarball/boost/boost/property_tree/json_parser/error.hpp: In instantiation of ‘boost::wrapexcept<E>::wrapexcept(const E&, const boost::source_location&) [with E = boost::property_tree::json_parser::json_parser_error]’: /home/noel/libo2/workdir/UnpackedTarball/boost/boost/throw_exception.hpp:171:11: required from ‘void boost::throw_exception(const E&, const source_location&) [with E = property_tree::json_parser::json_parser_error]’ /home/noel/libo2/workdir/UnpackedTarball/boost/boost/property_tree/json_parser/detail/write.hpp:159:13: required from ‘void boost::property_tree::json_parser::write_json_internal(std::basic_ostream<typename Ptree::key_type::value_type>&, const Ptree&, const std::string&, bool) [with Ptree = boost::property_tree::basic_ptree<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> >; typename Ptree::key_type::value_type = char; typename Ptree::key_type = std::__cxx11::basic_string<char>; typename Ptree::key_type::value_type = char; typename Ptree::key_type = std::__cxx11::basic_string<char>; std::string = std::__cxx11::basic_string<char>]’ /home/noel/libo2/workdir/UnpackedTarball/boost/boost/property_tree/json_parser.hpp:99:28: required from ‘void boost::property_tree::json_parser::write_json(std::basic_ostream<typename Ptree::key_type::value_type>&, const Ptree&, bool) [with Ptree = boost::property_tree::basic_ptree<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> >; typename Ptree::key_type::value_type = char; typename Ptree::key_type = std::__cxx11::basic_string<char>; typename Ptree::key_type::value_type = char; typename Ptree::key_type = std::__cxx11::basic_string<char>]’ /home/noel/libo2/sw/source/core/crsr/viscrs.cxx:129:37: required from here /home/noel/libo2/workdir/UnpackedTarball/boost/boost/property_tree/json_parser/error.hpp:20:11: warning: implicitly-declared ‘boost::property_tree::file_parser_error::file_parser_error(const boost::property_tree::file_parser_error&)’ is deprecated [-Wdeprecated-copy-dtor] 20 | class json_parser_error: public file_parser_error Change-Id: I1dd49af4d8c573a07b34d3216a36f283aaafa106 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163372 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-15Expat: upgrade to release 2.6.0Taichi Haradaguchi
Fixes CVE-2023-52425 and CVE-2023-52426. Change-Id: Id135bbaea893a83129bdbee44948c09322a64c07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163146 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-02-14Update pdfium to 6296Miklos Vajna
- external/pdfium/build.patch.1: drop most hunks which no longer apply, assuming they were only relevant for the RHEL 7 / C++17 baseline. Change-Id: Ida533485d81845a82d890f8c0b70fa61e201f880 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163329 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-12external/pdfium: Missing include (std::abs)Stephan Bergmann
Change-Id: Ia265f425cae86c671824ad355d6b91001c49adca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163236 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-08tdf#152524 use dispatch_async() instead of dispatch_sync()Patrick Luby
Commit 839cf255e2670fdf8e974af38432aacf63be4e90 used dispatch_sync() but, unfortunately, libdispatch will not create a new thread for the queue. dispatch_async_and_wait() also doesn't necessary run the queue in a separate thread so use dispatch_async() and block and wait for the libdispatch task to complete. Change-Id: I8babad30caa8a188483ddf4f62bae35f5b888dc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163122 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
2024-02-07external/zxcvbn-c: There is no std::basic_string<int>Stephan Bergmann
...and at least LLVM 19 trunk libc++ complains about it now since <c3668779c13596e223c26fbd49670d18cd638c40> "[libc++] Remove deprecated char_traits base template (#72694)" with > In file included from dict-generate.cpp:25: > In file included from ~/llvm/inst/bin/../include/c++/v1/iostream:43: > In file included from ~/llvm/inst/bin/../include/c++/v1/ios:223: > In file included from ~/llvm/inst/bin/../include/c++/v1/__locale:24: > ~/llvm/inst/bin/../include/c++/v1/string:746:43: error: implicit instantiation of undefined template 'std::char_traits<int>' > 746 | static_assert((is_same<_CharT, typename traits_type::char_type>::value), > | ^ > dict-generate.cpp:861:18: note: in instantiation of template class 'std::basic_string<int>' requested here > 861 | StringOfInts Chld; > | ^ > ~/llvm/inst/bin/../include/c++/v1/__fwd/string.h:23:29: note: template is declared here > 23 | struct _LIBCPP_TEMPLATE_VIS char_traits; > | ^ etc., so use a std::vector<int> instead Change-Id: I51e8296edf7b16925ff01679e671525256055552 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163048 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-07tdf#152524 fork() and exec() in a separate libdispatch queuePatrick Luby
This is another attempt to stop the crashing in libdispatch by running fork() and exec() within a libdispatch task that will run in a sequential queue in a non-main thread. Change-Id: I3249510c14cc32f7f769b59289fe8380dd22ab68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163036 Tested-by: Jenkins Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-29Experimental support for latest Emscripten (and Qt6)Stephan Bergmann
What I'm after in the context of our Embind-related code is the claim at <https://emscripten.org/docs/porting/connecting_cpp_and_javascript/embind.html#memory-management>: "JavaScript only gained support for finalizers in ECMAScript 2021, or ECMA-262 Edition 12. The new API is called FinalizationRegistry and it still does not offer any guarantees that the provided finalization callback will be called. Embind uses this for cleanup if available, but only for smart pointers, and only as a last resort." However, with the recommended emsdk 2.0.31 my tests did not show any use of that finalization support. So I wanted to try with the latest emsdk 3.1.51 instead. But then, linking vcldemo failed with > wasm-ld: error: ~/allotropia-qt5/lib/libQt5Core.a(qlogging.o): undefined symbol: std::__2::__vector_base_common<true>::__throw_length_error() const etc., so I gave it a try to rather build against latest Qt6.7, with > --with-distro=LibreOfficeWASM32 > --disable-qt5 > --enable-qt6 > QT6DIR=... TODO: The result is highly experimental, and it uses ENABLE_QT5 (i.e., the recommended setup with emsdk 2.0.31 and the <https://github.com/allotropia/qt5.git> v5.15.2+wasm branch) vs. ENABLE_QT6 (i.e., my experimental setup with emsdk 3.1.51 and the <https://github.com/qt/qt5.git> 6.7 branch) not only to distinguish between Qt5- vs. Qt6-specific behavior, but also to distinguish between old- vs. new-Emscripten-specific behavior. Of note: * The startup code appears to have changed substantially (and required setting -s MODULARIZE=1 and -s EXPORT_NAME=soffice_entry now, and telling emcc to build just soffice.js and not the wrapper soffice.html. TODO: This also required hacking into qt_soffice.html: (1) The command-line arguments (--norestore, --nologo, --writer, and the exammple.odt; all of which we should eventually get rid of, anyway). (2) Saving the generated instance as window.Module (and adapting the embindmaker-generated code, cf. the changes to static/README.wasm.md). * There were some symbol clashes between external/argon2 and libQt6Core.a(qcryptographichash.cpp.o, so renamed the problematic symbols in external/argon2. Change-Id: I5420ab566d560b11954ac6613249bfc53d8acb31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162695 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-23MAR update, too big to (not) failStephan Bergmann
On Windows, when a MAR update generated by create-partial-info contains very many patches (as easily happens with LibreOffice), applying it would fail with "failed: 7" (aka WRITE_ERROR, see workdir/UnpackedTarball/onlineupdate/onlineupdate/source/update/common/updatererror.h) because in workdir/UnpackedTarball/onlineupdate/onlineupdate/source/update/updater/updater.cpp PatchFile::mPatchStream holds open one FILE instance per patch from PatchFile::Prepare to PatchFile::Execute (and which can't easily be reworked because of the Lock/UnlockFile done on the underlying HANDLE "so it can't be messed with [in] between"), so calling NS_tfopen in PatchFile::Prepare will eventually start to fail with EMFILE. To avoid that, try to raise the limit to its maximum (but don't fail immediately if that fails, in case the given MAR update wouldn't run into the issue of too many patches, anyway), and keep fingers crossed. (See <https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmaxstdio?view=msvc-170> "_setmaxstdio" for details: "By default, up to 512 files can be open simultaneously at the stream I/O level. This level includes files opened and accessed using the fopen, fgetc, and fputc family of functions. The limit of 512 open files at the stream I/O level can be increased to a maximum of 8,192 by use of the _setmaxstdio function.") Change-Id: I6b3499f0f6c2060628418a15f5e36021bfe7dd18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162442 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-22Create MAR updates from msi rather than from archiveStephan Bergmann
...as the former is more convenient for release engineering (see the discussion in the comments at <https://gerrit.libreoffice.org/c/core/+/162157/1#message-8d7ebbcc64a87ee8e4a073ae1a05e3b74f5a3d6a> "Also enable --with-package-format=archive for LibreOfficeWin64.conf"). Instead of ONLINEUPDATE_MAR_OLDARCHIVE and ONLINEUPDATE_MAR_OLDMETADATA make variables, the create-partial-info target now only needs an ONLINEUPDATE_MAR_OLDMSI make variable. TODO: There are two issues when comparing the content of msi files (extracted with msiexec /a), which the old code comparing the content of archives had tried to somewhat (but not fully) address with the metadata files that I had invented (and now reverted): For one, msiexec /a also extracts content that would normally be installed somewhere else in the system (e.g., it extracts Fonts, System, and System64 directories). Differences in those directories will cause a MAR update to create those directories in the installation directory, rather than to update the corresponding files in their actual locations. For another, optional components are not recognized as such, but their content must be added to the MAR file as add/patch-if, not as plain add/patch. To work around that, for now *all* files are added as add/patch-if, conditional on the files themselves. Thus, addition of files will cause a MAR update to miss them. (As they now exclusively operate on msi files, the create-update-info and create-partial-info targets are no longer meaningful for non-Windows platforms, so drop the non-Windows bin/update/create_full_mar_for_languages.py part.) Change-Id: Ifb55b5e7d1a201b4f50a27cb449a634b96c2e29b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162399 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
generated by cgit (git 2.34.1) at 2025-01-07 22:54:19 +0000