Age | Commit message (Collapse) | Author |
|
While this fixes the build with --enable-wasm-exceptions, the
resulting binary generates an "indirect call signature mismatch",
which doesn't happen with the non-NEH build.
The Chrome DWARF backtrace points to CallbackTaskScheduling().
Further debugging reveals, it's actually the UpdateMinPeriod
call for the "desktop::Desktop m_firstRunTimer" Timer.
Disturbingly the debug dynamic_cast<Timer> at the start of the
job loop fails, and the fallback generic job output is
chosen, AKA:
info:vcl.schedule: 6516 0x3871618 i: 0 a: 1 p: 1 \
desktop::Desktop m_firstRunTimer
m_firstRunTimer is a Timer member in the Desktop class, so this
looks like some memory corruption or toolchain problem.
The size difference is more then 10% and it's supposed to be
faster too. FWIW the optimized link time is still high and needs
32GB+ memory compared to the 13GB non-optimized memory usage.
Change-Id: I06d37ecece09000fd3b72a73e7bf40f0b0f61457
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130216
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
More exotic locales like es-419 cannot be parsed by boost, so we
fall-back to the default encoding. This avoids an exception:
invalid_charset_error of the form:
"Invalid or unsupported charset:us-ascii or UTF-8"
for this case.
Change-Id: I6796dd893ec774b221956ea9febbcc19495d47b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130102
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
This header-only library is accurate in decimal representation of
doubles; provides API that allows to create custom representation
- so it's possible to use custom decimal separators and grouping.
This allows to unify all corner cases: integers, numbers close to
DBL_MAX, up-rounding to the next decade.
Note that Dragonbox creates the shortest decimal representation
of the number, that is unambiguously convertible back to the same
number; thus it may hide trailing digits that are unneeded for
such conversion.
The functional changes are minimal, and beneficial:
1. Rounding numbers close to DBL_MAX now takes into account the
bEraseTrailingDecZeros argument, as it should, allowing to have
"1.8E+308" for rounding DBL_MAX to 2 decimals without trailing
zeroes, instead of previous "1.80E+308".
2. Incorrect rounding is fixed in some cases, e.g. 9.9999999999999929
rounded to 10 previously using rtl_math_DecimalPlaces_Max.
3. Representing the number in the shortest way may change display
of some printed numbers. E.g., 5th greatest double is represented
as "1.797693134862315E+308" instead of a bit longer, but giving
the same double on roundtrip, "1.7976931348623149E+308". This would
generally look better for some numbers similar to the famous 0.1,
where users would likely expect more "round" representation where
it's unambiguous (but we still truncate to 15 significant decimals
anyway - so there's no point in pretending to provide exact digits
for actual binary representation).
These are reflected in the unit tests affected by the change.
Change-Id: I05e20274a30eec499593ee3e9ec070e1269232a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129948
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Fixes CVE-2021-30560
Change-Id: I334662ddc40955780321133be9aee23858e04dc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130065
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The two checks for __clang_major__ == 5 etc. had been added with
23a8d5ffbbe58761b89f590f0735abccd69a3681 "Upgrade external/boost to
Boost 1.69.0" because "with the non-standard Clang 5.0.300080 from NDK r16b, the
build now caused failures". But for our current Android build baseline NDK r19c
(cf. README.md),
> $ android-ndk-r19c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --version
> Android (5058415 based on r339409) clang version 8.0.2 (https://android.googlesource.com/toolchain/clang 40173bab62ec746213857d083c0e8b0abb568790) (https://android.googlesource.com/toolchain/llvm 7a6618d69e7e8111e1d49dc9e7813767c5ca756a) (based on LLVM 8.0.2svn)
[...]
has __clang_major__ == 8 by now.
Change-Id: I5a5131c14ddf410ed60337992c2d827792c3bbc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130029
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
All the tested cross builds don't build galleries, so the
cross-toolset won't contain gengal and no vcl is build.
To fix the full static build, add LIBWEBP to the list of
PERMITTED_BUILD_TARGETS and use gb_CONFIGURE_PLATFORMS to
provide the --host and --build flags.
Regression from commit 60eaa424c5e213f31227008e1ed66a646491a360
("support for the WebP image format (tdf#114532)").
Change-Id: I017c4fc72456859616d535ddfb2d568442ffa446
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129790
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
...fixing
> Makefile.vc(18) : fatal error U1050: Unable to auto-detect toolchain architecture! If cl.exe is in your PATH rerun nmake with ARCH=<arch>.
because workdir/UnpackedTarball/libwebp/Makefile.vc naively relies on cl.exe-
specific output details in
> !IFNDEF ARCH
> !IF ! [ $(CC) 2>&1 | grep -q "x86" > NUL ]
> ARCH = x86
> !ELSE IF ! [ $(CC) 2>&1 | grep -q "x64" > NUL ]
> ARCH = x64
> !ELSE IF ! [ $(CC) 2>&1 | grep -q "ARM" > NUL ]
> ARCH = ARM
> !ELSE
> !ERROR Unable to auto-detect toolchain architecture! \
> If cl.exe is in your PATH rerun nmake with ARCH=<arch>.
> !ENDIF
> !ENDIF
Change-Id: I376295fc75d6ab19773e53dbb607d3b156fbe948
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129655
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
std::runtime_exception of:
"Invalid or unsupported charset:UTF-8 or UTF-8"
is less useful than it could be when spat out from the boost gettext
impl. Survive for the next (and probably more useful) exception.
Change-Id: Ibeb60b4a34f09f47051844c3e8048f38618d0e05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129566
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
This commit implements a WebP reader and writer for both lossless
and lossy WebP, export dialog options for selecting lossless/lossy
and quality for lossy, and various internal support for the format.
Since writing WebP to e.g. ODT documents would make those images
unreadable by previous versions with no WebP support, support
for that is explicitly disabled in GraphicFilter, to be enabled
somewhen later.
Change-Id: I9b10f6da6faa78a0bb74415a92e9f163c14685f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128920
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
No idea why we just provided the platform flags when cross-
compiling. In the curious case, where the host platform is
detected as x86_64-pc-mingw32 per default and we actually
want to override it with x86_64-pc-cygwin, we don't do a
cross compile, but must override the host platform.
But there is additional special handling needed for the omitted
cross-platform build in the special case of --host=i686-pc-cygwin
and --build=x86_64-pc-cygwin, where we deliberatly ignore cross
building; Windows is already a slow build, so try to keep this
optimization (AMD64 can execute x86 binaries).
There is the theoretical case, where the externals config.guess
would have detected something else and that "magically" even
worked, while the LO detected triplet would fail, but this
should be fixed in the external in any way.
Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: Ie141268793dc4332d8c253bec4e986894682c7a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129179
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
wget https://github.com/libexpat/libexpat/pull/550.patch -O CVE-2022-23852.patch
wget https://github.com/libexpat/libexpat/pull/551.patch -O CVE-2022-23990.patch
Change-Id: I1f2694abd9f577e0b4fedbf27118b52be8a1a688
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129124
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
> In file included from workdir/UnpackedTarball/mdds/include/mdds/flat_segment_tree.hpp:37,
> from sc/inc/columnspanset.hxx:16,
> from sc/source/core/data/columnspanset.cxx:10:
> In function ‘void mdds::__st::intrusive_ptr_add_ref(node<T>*) [with T = mdds::flat_segment_tree<int, bool>]’,
> inlined from ‘boost::intrusive_ptr<T>::intrusive_ptr(const boost::intrusive_ptr<T>&) [with T = mdds::__st::node<mdds::flat_segment_tree<int, bool> >]’ at workdir/UnpackedTarball/boost/boost/smart_ptr/intrusive_ptr.hpp:93:44,
> inlined from ‘boost::intrusive_ptr<T>& boost::intrusive_ptr<T>::operator=(const boost::intrusive_ptr<T>&) [with T = mdds::__st::node<mdds::flat_segment_tree<int, bool> >]’ at workdir/UnpackedTarball/boost/boost/smart_ptr/intrusive_ptr.hpp:154:9,
> inlined from ‘mdds::flat_segment_tree<_Key, _Value>::flat_segment_tree(const mdds::flat_segment_tree<_Key, _Value>&) [with _Key = int; _Value = bool]’ at workdir/UnpackedTarball/mdds/include/mdds/flat_segment_tree_def.inl:88:25:
> workdir/UnpackedTarball/mdds/include/mdds/node.hpp:244:10: error: pointer used after ‘void operator delete(void*, std::size_t)’ [-Werror=use-after-free]
> 244 | ++p->refcount;
> | ~~~^~~~~~~~
> In function ‘void mdds::__st::intrusive_ptr_release(node<T>*) [with T = mdds::flat_segment_tree<int, bool>]’,
> inlined from ‘void mdds::__st::intrusive_ptr_release(node<T>*) [with T = mdds::flat_segment_tree<int, bool>]’ at workdir/UnpackedTarball/mdds/include/mdds/node.hpp:248:13,
> inlined from ‘boost::intrusive_ptr<T>::~intrusive_ptr() [with T = mdds::__st::node<mdds::flat_segment_tree<int, bool> >]’ at workdir/UnpackedTarball/boost/boost/smart_ptr/intrusive_ptr.hpp:98:44,
> inlined from ‘boost::intrusive_ptr<T>& boost::intrusive_ptr<T>::operator=(const boost::intrusive_ptr<T>&) [with T = mdds::__st::node<mdds::flat_segment_tree<int, bool> >]’ at workdir/UnpackedTarball/boost/boost/smart_ptr/intrusive_ptr.hpp:154:9,
> inlined from ‘mdds::flat_segment_tree<_Key, _Value>::flat_segment_tree(const mdds::flat_segment_tree<_Key, _Value>&) [with _Key = int; _Value = bool]’ at workdir/UnpackedTarball/mdds/include/mdds/flat_segment_tree_def.inl:87:19:
> workdir/UnpackedTarball/mdds/include/mdds/node.hpp:252:9: note: call to ‘void operator delete(void*, std::size_t)’ here
> 252 | delete p;
> | ^~~~~~~~
etc. The warning is apparently new in GCC 12 trunk (see
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=671a283636de75f7ed638ee6b01ed2d44361b8b6>
"Add -Wuse-after-free [PR80532]"), and I'm not entirely sure whether this
is a true or false positive, but the fix looks somewhat plausible, and at least
also my (Clang) ASan+UBSan build does a successful `make check` with (and
without) this change.
Change-Id: I63fafceba8d1b4e0ddd7cf2e58403a3bc763e53c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129008
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This fixes the same issue as
<https://github.com/curl/curl/commit/e39421cef31f13a19b6bef5c644978e0c54e4e16>
"curl-functions.m4: fix LIBRARY_PATH adjustment to avoid eval", just in a less
intrusive way so that we can get away with just fixing the resulting configure
rather than having to run any Autotools reconfiguration commands.
40a84af1bdd7b3c414a8a78ca32b0951c03f9976 "upgrade to curl-7.81.0" caused
<https://ci.libreoffice.org/job/lo_ubsan/2272/> to fail with the cryptic
[...]
> checking for gethostbyname in -lnetwork... no
> checking for gethostbyname in -lnet... no
> configure: error: couldn't find libraries for gethostbyname()
> /home/tdf/lode/jenkins/workspace/lo_ubsan/external/curl/ExternalProject_curl.mk:41: recipe for target '/home/tdf/lode/jenkins/workspace/lo_ubsan/workdir/ExternalProject/curl/build' failed
> make[1]: *** [/home/tdf/lode/jenkins/workspace/lo_ubsan/workdir/ExternalProject/curl/build] Error 1
because somewhere in the middle of curl's configure LD_LIBRARY_PATH got garbled
because of this issue, so that invoking
/home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang started to fail with
> /home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang)
> /home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang)
> /home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang)
(because that clang is built against a local GCC and libstdc++, so needs
LD_LIBRARY_PATH to be set up properly to find the latter), which caused the
gethostbyname check to fail (as seen when looking into that build's
workdir/UnpackedTarball/curl/config.log).
Change-Id: I3d45018cdfdb22b98c0dec0757e754a172a811de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128850
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I618467eb37ea578c17dab0810f0ed5ad160f1552
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128789
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I0a34239bfb16bf19e25bf374c7f36c4cdf1776c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128783
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
... resulting in a stripped-down, Writer-only build to decrease
the resulting WASM bytecode size.
It removes the following code from the build:
* All other major modules: Base, Calc, Chart, Draw, Impress and
Math and related writerperfect filters
* The premultiply tables
* The (auto-)recovery functionality
* All accessibility (but not the accessibility document checker)
* The LanguageGuess component
* EPUB support
* The start center / BackingWindow
* The TipOfTheDay functionality
* The splash screen communication
Currently crashs with anything different then soffice --writer.
Closing the document also still crashes.
FYI: many of these features are now behind ENABLE_WASM_STRIP_*
defines, but they normally don't work on their own, globally!
That's because we started with stripping the main components.
Change-Id: Ib9c0f9452815910c0a2aceaf142ba1ad4a9cb0d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126182
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
We probably want to pre-create the fontconfig cache in the image.
Startup time still is not really worse for me, but YMMV.
Change-Id: I419682339dd6d943753de9043ff82f2fb877b168
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128624
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
...turning the latter into "whatever include directories are needed for the
given toolchain and platform, outside the scope of LibreOffice". This is a
prerequisite for fixing <https://gerrit.libreoffice.org/c/core/+/128591/1> "Let
CppunitTest_odk_checkapi build against the SDK include directory", which failed
to find the C++ standard library headers (available via SOLARINC) on Windows.
(In external/icu/ExternalProject_icu.mk, SRCDIR/include is needed for ANDROID to
find <android/compatibility.hxx> in external/icu/icu4c-android.patch.1.)
Change-Id: I960e31140b0839b2b6184a78d935042c3c558d5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128615
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
boost probably expects a WASI, not Emscripten.
Change-Id: I7f275e1b501d6ea46d43637be815bf5a45b1cc40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128586
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
All the small stuff, which is needed for the WASM build, but is
not really worth an extra patch.
* No soffice.sh script needed for WASM
* WASM soffice.bin executable extension is html
* Some small additional SAL_LOG output
* Default to colibre icon theme
* Test for qt5 even without X11
* Remove emconfigure artefacts at the end of the configure run
* No oosplash for WASM
* Disable the Office IPC thread
* Suppress -Wno-enum-conversion for Cairo builds
* Fix libnumbertext by using gb_EMSCRIPTEN_CPPFLAGS
* Map EMSCRIPTEN to LINUX nls
* No extra newlines for missing icon theme images
* Print the missing dependency in some gbuild error messages
* Copy Qt WASM loader, HTML template and SVG logo for binaries
* Especially build the vcldemo for Emscripten
Change-Id: I356370c72cc09357411e14d0c00762152877a800
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128584
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
and popppler-data to 0.4.11
Change-Id: Ibd8c28f36408a670b5853f1b266c6b8c36916a61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128398
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I68751a7b6ca2c8c86a412a0fd401e0d0f172297b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128353
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
...to prevent Library_skia from failing to link with
> /usr/bin/ld.gold: error: workdir/UnpackedTarball/fontconfig/src/.libs/libfontconfig.a(fccfg.o): requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC
etc. in a --without-system-fontconfig build
Change-Id: Idd09785096d1a8be3f3086d6e565f307fa046a60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128267
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The pkgdata tool basically not only generates the data, but
forces a non-parallel build for all data files for platforms,
which can't use the (single file) assembler mode. This hits
the WASM build, bringing down the parallel build to a crawl.
But there is already the "hidden" optimization implemented in
pkgdata to just write a single C source file, instead of one
per locale. For some reason, that is just enabled on OS400.
I don't think we have a platform, which would have a memory
restriction doing this, so just uncondition this pkgdata
build mode for everyone.
Feel free to otherwise condition this patch for your platform
in external/icu/UnpackedTarball_icu.mk.
Change-Id: I482d80e853128d00faa43687e38f5b88fbf6958c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128266
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
> workdir/UnpackedTarball/freetype/src/autofit/aflatin.c:1992:44: runtime error: applying zero offset to null pointer
etc. seen during CppunitTest_sd_misc_tests etc.
Change-Id: Id85c4331f9a892d99e4f3b9cae37b4ffe8c53973
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128034
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2b13aceffd9932978c98c49bc688bd5f71690523
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128035
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
* remove GPGME_CAN_EXPORT_MINIMAL_KEY, upstream now has support for
key export flags in c++ wrapper (gpgmepp >= 1.14)
* therefore, external/gpgmepp/add-minimal-keyexport.patch now fully
obsolete, tweaked xmlsecurity code to use upstream function
* bits of external/gpgmepp/find-libgpg-error-libassuan.patch are
upstream now (configure and makefile pieces, though we keep
configure.ac changes for the while - to not pick up system versions
too easily)
* external/gpgmepp/gpgme.git-fe2892618c20cd40c342cce26ffb6ac4644fd3c3.patch.1
was from upstream anyway, removed
Change-Id: I991c20c0eeff0f9135e97c991afcb905be55a959
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127665
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Change-Id: Icd1034f4c6b43605f5d43fe28f7e0d191311daf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127664
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Change-Id: Iecd4a131f9c5b43bb03c5f9c4b6c7efe36e443aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127663
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
...instead of having its configure.ac determine whether to support png based on
it being installed on the system, but which then might cause a Linux
--without-system-freetype build to fail to link Library_pdfium with
> workdir/UnpackedTarball/freetype/src/sfnt/pngshim.c:199: error: undefined reference to 'png_get_error_ptr'
etc.
Change-Id: Idf47ba5252b8f4d7f2e295f7adf6b761dbee4d2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127985
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...to prevent Library_pdfium from failing to link with
> ld.lld: error: relocation R_X86_64_64 cannot be used against local symbol; recompile with -fPIC
> >>> defined in workdir/UnpackedTarball/freetype/instdir/lib/libfreetype.a(ftinit.o)
> >>> referenced by ftinit.c:89 (src/base/ftinit.c:89)
> >>> ftinit.o:(FT_Add_Default_Modules) in archive workdir/UnpackedTarball/freetype/instdir/lib/libfreetype.a
etc., presumably since 8677e994d37329a28ca8278358a99d18b9cada69 "Simplify
FONTCONFIG and FREETYPE tests" no longer implicitly forces use of system
freetype on Linux
Change-Id: I2743619768e2dd636ec431408fcb2871871504f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127864
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Re-generated configure file gets confused & claims not finding C89-
compatible compiler for gcc-wrapper-building libassuan with msvc
underneath.
Work-around the problem by telling toolchain right off that this
_is_ a std c compliant compiler.
Change-Id: I4fa23673b790bc70a9294951df545c27f5236f81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127641
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
With Windows 11 SDK (10.0.22000.0).
Error message is:
fatal error RC1116: RC terminating after preprocessor errors
https://bugs.python.org/issue45220
Applied fixing patches to 3.8.
Change-Id: I0860b05fd963ea81b493a4b9df7f39db86598dd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127395
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I76c0d57da63c1e35f80b13071793dbbb27cb218a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126655
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
Remove code in ucb/source/ucp/webdav-neon, and now unused external
neon.
The --with-webdav=no option is retained for now.
Change-Id: I4ce429587e3991fa82009da2f8e4a068abe36435
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126839
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Remove code in ucb/source/ucp/webdav, and now unused externals
apr, apr-util, serf.
Change-Id: I31ab8bb1491f5290e175e87f2b30499811c5a359
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126835
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
|
|
Change-Id: Id28cd361237ce67b76a865ad4291ccece521af85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126768
Tested-by: Jenkins
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I7d5e5432d75caf671434977b48b415839cbf90b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126795
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
see: https://github.com/nu-book/zxing-cpp/pull/269
CVE-2021-28021 CVE-2021-42715 CVE-2021-42716
though it's unclear if there is any relevence to our usage of zxing-cpp
Change-Id: I30fa7682af56c432b651d8c0385f1b85c3582101
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126647
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...than ae36ee4f3aa544e53e2edad93d6d79160b27bc9d "Work around use-after-poison"
for
> ==1922539==ERROR: AddressSanitizer: use-after-poison on address
> 0x61d00190fab0 at pc 0x00000026aaa9 bp 0x7f422ee84b80 sp
> 0x7f422ee84348 WRITE of size 192 at 0x61d00190fab0 thread T44 #0 in
> memset at
> ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:800:3
> (instdir/program/soffice.bin +0x26aaa8) #1 at <null>
> (/lib64/libnsspem.so +0x15f3d) #2 at <null> (/lib64/libnsspem.so
> +0x16185) #3 at <null> (/lib64/libnsspem.so +0x8a9b) #4 at <null>
> (/lib64/libnsspem.so +0xe13b) #5 in secmod_ModuleInit at
> workdir/UnpackedTarball/nss/nss/lib/pk11wrap/pk11load.c:244:11
> (instdir/program/libnss3.so +0x4ad372) #6 in secmod_LoadPKCS11Module
> at workdir/UnpackedTarball/nss/nss/lib/pk11wrap/pk11load.c:544:10
> (instdir/program/libnss3.so +0x4b1fca) #7 in SECMOD_LoadModule at
> workdir/UnpackedTarball/nss/nss/lib/pk11wrap/pk11pars.c:1946:10
> (instdir/program/libnss3.so +0x50de92) #8 in SECMOD_LoadUserModule
> at workdir/UnpackedTarball/nss/nss/lib/pk11wrap/pk11pars.c:2042:28
> (instdir/program/libnss3.so +0x50e9a9) #9 in nss_load_module at
> workdir/UnpackedTarball/curl/lib/vtls/nss.c:1310:12
> (instdir/program/libcurl.so.4 +0x4fdd25) #10 in nss_setup_connect at
> workdir/UnpackedTarball/curl/lib/vtls/nss.c:1894:12
> (instdir/program/libcurl.so.4 +0x4eeffb) #11 in nss_connect_common
> at workdir/UnpackedTarball/curl/lib/vtls/nss.c:2235:14
> (instdir/program/libcurl.so.4 +0x4ee237) #12 in
> nss_connect_nonblocking at
> workdir/UnpackedTarball/curl/lib/vtls/nss.c:2291:10
> (instdir/program/libcurl.so.4 +0x4ebe4a) #13 in
> Curl_ssl_connect_nonblocking at
> workdir/UnpackedTarball/curl/lib/vtls/vtls.c:361:12
> (instdir/program/libcurl.so.4 +0x514039) #14 in https_connecting at
> workdir/UnpackedTarball/curl/lib/http.c:1591:12
> (instdir/program/libcurl.so.4 +0x2f29ce) #15 in Curl_http_connect at
> workdir/UnpackedTarball/curl/lib/http.c:1517:14
> (instdir/program/libcurl.so.4 +0x2f23d5) #16 in protocol_connect at
> workdir/UnpackedTarball/curl/lib/multi.c:1696:16
> (instdir/program/libcurl.so.4 +0x3b8620) #17 in multi_runsingle at
> workdir/UnpackedTarball/curl/lib/multi.c:1997:16
> (instdir/program/libcurl.so.4 +0x3a2232) #18 in curl_multi_perform
> at workdir/UnpackedTarball/curl/lib/multi.c:2568:14
> (instdir/program/libcurl.so.4 +0x39dc5c) #19 in
> http_dav_ucp::CurlProcessor::ProcessRequestImpl(http_dav_ucp::CurlSession&,
> http_dav_ucp::CurlUri const&, curl_slist*,
> com::sun::star::uno::Reference<com::sun::star::io::XOutputStream>
> const*, com::sun::star::uno::Sequence<signed char> const*,
> std::pair<std::__debug::vector<rtl::OUString,
> std::allocator<rtl::OUString> > const&, http_dav_ucp::DAVResource&>
> const*, (anonymous namespace)::ResponseHeaders&) at
> ucb/source/ucp/webdav-curl/CurlSession.cxx:880:14
> (instdir/program/../program/libucpdav1.so +0x5aad30) 0x61d00190fab0
> is located 48 bytes inside of 2048-byte region
> [0x61d00190fa80,0x61d001910280) allocated by thread T44 here: #0 in
> malloc at
> ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3
> (instdir/program/soffice.bin +0x2d3c7e) #1 in PR_Malloc at
> workdir/UnpackedTarball/nss/nspr/out/pr/src/malloc/../../../../pr/src/malloc/prmem.c:448:55
> (instdir/program/libnspr4.so +0x123629) #2 in PL_ArenaAllocate at
> workdir/UnpackedTarball/nss/nspr/out/lib/ds/../../../lib/ds/plarena.c:134:27
> (instdir/program/libplds4.so +0x9a32) #3 at <null>
> (/lib64/libnsspem.so +0x15f77)
during UITest_sw_options:
That --with-system-nss workaround for <https://ci.libreoffice.org/job/lo_ubsan/>
had caused CppunitTest_desktop_lib to start to fail there, presumably "caused by
--with-system-nss on the CentOS7 baseline", see the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2021-December/088136.html>
"Re: [global-libreoffice-ci] UBSAN Linux Build - Build # 2217 - Still Failing!"
And while I had initially not been able to reproduce the use-after-poison during
UITest_sw_options with my local ASan+UBSan build (on Fedora 35), I now found out
that that was just because my machine happened to not have an nsspem library
installed in the system (the nss-pem RPM on Fedora). With that system library
installed, my local build failed UITest_sw_options in the same way as the
Jenkins tinderbox.
Which lead me to the idea of avoiding the whole mess by avoiding that CUrl loads
the (apparently optional) nsspem library in ASan builds altogether. (Another
approach might have been to disable the __asan_poison_memory_region
functionality in workdir/UnpackedTarball/nss/nspr/lib/ds/plarena.h, but the
chosen approach nicely makes us less dependent on accidental differences in
build-time execution environments, at least for ASan builds.)
Change-Id: I8fd2ff255771622f26ad666ca78a6d9ded0af2d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8507c101544fcdcdc6e75c853c44e04e97a96d91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126411
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
WASM strictly checks function signatures, so forced wrong
casting of function pointers compiles, but any call will
generate a runtime error, even if the argument is actually
ignored.
So this adds a bunch of wrapper functions to pass instead.
Change-Id: Id976ea3ca81a792c8af539884ef741f5d23fc2c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126317
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
When building a static LO with --disable-dynloading on Linux,
--without-system-libs failed for me. And it left me really puzzled:
raptor configure failed and claimed it couldn't link libxml2.
raptor's config.log showed missing math functions. xml2-config of
LO's build is patched and it includes a -lm. The xml2-config in my
chroot doesn't. But we explicitly pass the xml2-config for
non-system-libxml2 build. Reading the configure from raptor didn't
reveal a way, that it could somehow pick up the xml2-config from
the chroot, but that code is autoconf-complex...
When running "sh -x configure", it turned out the configure script
actually picks up the LIBXML_* flags from the environment, which
are set by LO's config_host.mk. These just add -lm for Android.
So this adds a xml2-config.in "dummy", which overwrites the one
from the libxml2 source and just echos LO's LIBXML_* values and
it adds -lm for all DISABLE_DYNLOADING targets.
Change-Id: Ia713cf80c8e7dc989cf23c224e7a0f7ea1210a87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116409
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Up until now this has been implemented like in almost all other VCL
backends by manually xor-ing pixel values. But that required fetching
pixel values from the GPU in Vulkan mode, which is relatively slow.
Since some time Skia now has supported writing custom blending modes
using the SkBlender class, so it's now possible to drop the hack
and support xor drawing directly using a blender that does
the operation. This should be both faster and simpler.
Change-Id: Id751d0ed4034852ce68697ecf56cc6dfac95307f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126051
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I55ab0b25389dcce3263b38a2de12c437b47751c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125821
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I270cbb75cde2a44416b61978b8eefdf267720031
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125559
Tested-by: Jenkins
Reviewed-by: René Engelhard <rene@debian.org>
|
|
There's no official MSVC support in ccache yet, but there are patches
in progress of getting upstreamed. So right now it's necessary
to get a patched ccache.
Ccache cannot work with -Zi option, since sharing debuginfo in a .PDB
cannot be cached. Added --enable-z7-symbols that gets enabled
by default if ccache is detected.
It works even with PCHs enabled, and externals seem to work too.
I get almost 100% hit rate on a rebuild, although such a rebuild
is slower than on Linux.
Change-Id: I1d230ee1fccc441b9d9bec794cc2e1ec13161999
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125179
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
with many documents, e.g. moz377878-1.xhtml
https: //gitlab.com/orcus/orcus/-/merge_requests/113
Change-Id: I085543ebb28c02a1c0ec487b357f6e0a83004363
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125378
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Unicode 14, 5 new scripts, 12 new Unicode blocks.
In i18npool/qa/cppunit/test_breakiterator.cxx
TestBreakIterator::testLao() had to be disabled/adapted.
Needs to be investigated, see comments there.
As is, Lao script word break has regressions.
Correct UBLOCK_TANGUT_SUPPLEMENT Unicode range endpoint to
0x18D7F, see
https://www.unicode.org/versions/Unicode14.0.0/erratafixed.html
for which ublock_getCode(0x18D8F) now returned UBLOCK_NO_BLOCK and
thus luckily the assert in svx/source/dialog/charmap.cxx hit.
Change-Id: I4bad16ecfab3f44be365b8f884c57f34af68218e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125322
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|