summaryrefslogtreecommitdiff
path: root/external
AgeCommit message (Collapse)Author
2021-08-02Mark external/libodfgen/ellipticalarc.patch as reported upstreamStephan Bergmann
Change-Id: I76f8cab70d4c1a5b98bb5ba1608676d34570694b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119879 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-01external/libodfgen: Avoid division by zero for empty elliptical arcStephan Bergmann
...as seen when running under UBSan `instdir/program/soffice --headless --convert-to epub` of caolan/libmspub_icu_global_buffer_overflow.sample from the crash-testing corpus. <https://www.w3.org/TR/SVG11/implnote.html#ArcImplementationNotes> specifies: "If the endpoints (x1, y1) and (x2, y2) are identical, then this is equivalent to omitting the elliptical arc segment entirely." (And getEllipticalArgBox's xmin, ymin, xmax, and ymax out parameters are pre-filled with suitable values at the call site in getPathBBox, so that we can return here without setting those out parameters.) Change-Id: I6b0b693354648f4015cec2395737fb9abe5ae956 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119680 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-28tdf#101630 - gdrive support w/oAuth and Drive API v3Christian Lohmaier
LibreOffice is only using drive.file scope, so can only see files it owns/that were created by LibreOffice. In addition, also store the refresh token in LO's password-store if the user enabled persistent storage, removing the need to to the copy'n'paste dance to grant access each time LO is launched. related tdf#115643 also store the refresh token for onedrive consolidate the fallback-auth provides for onedrive/gdrive into one, they are all the same login in browser, then copy code method that ultimately should be changed to having LO listen on local port for the code Change-Id: I97e3843682c302d2884e35ece6e72bc3a07e2539 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119572 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-07-26build Skia also on MacLuboš Luňák
This only builds the library, without using it. Change-Id: I54e940bcaa61852b831dbe7ae5660a5daf5fe609 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119356 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-07-22curl: upgrade to release 7.78.0Michael Stahl
* Fixes CVE-2020-8284 CVE-2021-22924 * Also fixes these which don't look relevant to LO: CVE-2020-8231 CVE-2020-8285 CVE-2020-8286 CVE-2021-22876 CVE-2021-22890 CVE-2021-22897 CVE-2021-22898 CVE-2021-22901 CVE-2021-22922 CVE-2021-22923 CVE-2021-22925 CVE-2021-22926 * disable some new protocols and dependencies * remove curl-ios.patch.1 as the code no longer exists upstream Change-Id: I12d5f87f4d503a5f9859226a05cfe2a07e46d993 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119313 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-07-20tdf#143429: update harfbuzz to 2.8.2 versionJulien Nabet
Change-Id: I263dc6da5be3ea55205076a1f4e263fe5bba31fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119232 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-07-14external: update pdfium to 4568Miklos Vajna
Change-Id: I2bfd5f806281e747702d423b7e59b5f88a7bea9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118868 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-07-07tdf#133368: update extensions website URLs and use httpsStéphane Guillou
Change-Id: Idcdb5dbb4f0754425eeca4b137fa1626bba9ef6a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118340 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-06-28Mark external/harfbuzz/Wunused-but-set-variable.patch as fixed upstreamStephan Bergmann
Change-Id: Iefc8f4f6ff93ec1a11256724b1881689d5eb56d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117992 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-25Silence -Werror,-Wunused-but-set-variable (clang-cl 13 trunk)Stephan Bergmann
...during build of ExternalProject_harfbuzz: > In file included from hb-ot-shape-complex-myanmar.cc:136: > hb-ot-shape-complex-myanmar-machine.rl(108,36): error: variable 'act' set but not used [-Werror,-Wunused-but-set-variable] > unsigned int p, pe, eof, ts, te, act HB_UNUSED; > ^ Change-Id: Ie75a5cfa16c29c02e1b97380ebd63e7d789926f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117850 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-25python3: update to 3.8.10Jan-Marek Glogowski
So we don't build 3.8.8rc1 anymore. I didn't look into 3.9. Change-Id: Ife7d898c913b9b164168b0ef23a055deea55815f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117757 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-06-24breakpad: don't include the users's env in linux dumpsChristian Lohmaier
Change-Id: I004b862295686789c0a88dc678bd098d81c76421 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117503 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-06-23tdf#141709: Use poppler_dataMichael Warner
Bundle the files from poppler_data and provide the path to them to poppler when the bundled poppler library is used. Change-Id: I13a2ef861303a0be17aa0a861ef8ac96ed8a93be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117523 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-06-22configure: Improve help-options handlingJan-Marek Glogowski
This patch includes: * A README.help.md as a general documentation for the different help types, the LO code and help-related build options. * Adds --disable-xmlhelp for removing the xmlhelp support from the build. Disable for iOS, Android and Emscripten. This was partly included in HAVE_FEATURE_DESKTOP before. * Rename WITH_HELP define to WITH_HELPPACKS, which reflects the actual usage AFAIK. * Depend --with-omindex on --with-help=online and don't override the --with-help setting. Error out on conflicting options. * Depend --with-helppack-integration on build help variants, which actually result in help packs. Kind of reverts commit 2c38ea6d16b910294220cefaf8ae6a0683e6405a ("Building without --with-help is not supposed to disable help functionality"). Change-Id: Ie4cb73905b3ed94e991d9f1bd75cfbd6de9da385 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116222 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-06-11use freshly compiled dump_syms.exe on windows for symbolinfo extractionChristian Lohmaier
while self compiled one still segfaults frequently, it is a tad better than the included one (and compiling froms source instead of using precompiled binaries is a net win in any case) Out of 50 attempts with the mergedlo.dll, the new compiled dump_syms succeeded 11 times, the shipped one succeeded 7 times - so could still be regular variance in that small sample size, but at least not significantly worse either. Change-Id: I86c213fe6aece58f1391d4c2bf9906b85eee9c57 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117056 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-06-10external/mdds: Mark patch as upstreamedStephan Bergmann
Change-Id: Id61fbaafb575a8c745e5b3cc5b2ff8ae4526d94c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116960 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-09external/pdfium: Latest MSVC now needs the GCC workaround, tooStephan Bergmann
...or else a build with MS VS 2019 16.10.0 and --with-latest-c++ would cause a stack overflow during CppunitTest_xmlsecurity_pdfsigning in the same way as described at 6391e3c4dcd4d61c2f95f996e797e49b5586dbd1 "external/pdfium: Work around GCC C++20 recursive comparison issue". Interestingly, builds with recent Clang (on various platforms) and --with-latest-c++ do not run into that stack overflow issue, so it appears that Clang implements subtly different rules for C++20 and beyond here than do GCC and MSVC. (The GCC issue <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141> "c++20 rewritten operator== recursive call mixing friend and external operators for template class" mentioned in external/pdfium/UnpackedTarball_pdfium.mk may not be the most accurate description of the precise issue at hand here, but lets keep it at that for now. Its comments do mention "that some people are going to try and change the rules to avoid breaking code like this.") But regardless of what the exact rules are for C++20 and beyond, these problematic overloads are only needed for C++17 and earlier anyway, as C++20 can cover them with automatic rewrites of other operators. So lets generally disable them for C++20 and beyond. Change-Id: I99033d6f09f069f00a6916ef40fd03dd4962a5c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116882 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-09external/mdds: -Werror,-Wunused-but-set-variable (Clang 13 trunk)Stephan Bergmann
> In file included from svl/source/misc/gridprinter.cxx:16: > In file included from workdir/UnpackedTarball/mdds/include/mdds/multi_type_matrix.hpp:37: > In file included from workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector.hpp:1358: > workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector_def.inl:851:15: error: variable 'start_pos' set but not used [-Werror,-Wunused-but-set-variable] > size_type start_pos = m_cur_size; > ^ > workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector_def.inl:3926:15: error: variable 'start_row_itr' set but not used [-Werror,-Wunused-but-set-variable] > size_type start_row_itr = start_row_in_block1; > ^ Change-Id: I1f5e7e1f6a2b8457eb6d65dbd65336d3684c2b89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116808 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2021-06-07pass -enable-symbols down to libxmlNoel Grandin
Change-Id: Iceef587366bebe6007f40e100f19e6a2f048adda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116764 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-03external/cairo: Fix previous -fsanitize=alignment fixStephan Bergmann
13f6d80330208eeb45fe9a03bb462941fb4eda2a "external/cairo: Support building with ASan/UBSan" had added the src/cairo-image-source.c blob to external/cairo/cairo/san.patch.0 to fix > > cairo-image-source.c:512:10: runtime error: load of misaligned address 0x6180037aee6f for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment > during UITest_writer_tests7 I had created that patch attempting to do a faithful emulation of the original code (which I had naively assumed to be correct, modulo the alignment issue), reading four consecutive bytes and interpreting them as an uint32_t in the system's byte order. I had not noticed back then that all that CAIRO_FORMAT_RGB24_888 was added by external/cairo/cairo/cairo-1.10.2.patch, introduced with 54596087e57ea533253e19eea594d9b6c06e8d26 "vcl-svp: add 24-bit (3-byte) RGB surface support to Cairo". Its > + * @CAIRO_FORMAT_RGB24_888: each pixel is a 24-bit quantity, > + * with Red, Green, Blue taking 8-bits each, in that order. (Since 1.1x) and > + * Need this until CAIRO_FORMAT_RGB24_888 is in some official release. > + * Otherwise we can't reliably check if this is available or we should > + * convert from 24-bit RGB to 32-bit RGB before passing to Cairo. comments make it sound as if this code might come from some official cairo upstream branch, but I cannot find anything at git.freedesktop.org/git/cairo. I have no idea about the provenance and quality of that code. However, I now (a) from the above comments naively assume that the intent of CAIRO_FORMAT_RGB24_888 is to store R, G, B in that order in three bytes with increasing addresses (i.e., independent of the system's byte order for larger- than-byte words); (b) thus consider the original src/cairo-image-source.c code in external/cairo/cairo/cairo-1.10.2.patch broken (as it attempts to read all three values in one read, in system byte order, which would fail for big endian); and (c) thus consider the faithful emulation code in external/cairo/cairo/san.patch.0 to be broken, too. Based on the above, I here fix at least the external/cairo/cairo/san.patch.0 code (which is applied unconditionally, even for non-ASan/UBSan builds, thus always overriding the original external/cairo/cairo/cairo-1.10.2.patch code). The following line > pixel &= 0x00ffffff; /* ignore next pixel bits */ should no longer be necessary now, and it is probably better to directly fix the original code in external/cairo/cairo/cairo-1.10.2.patch, but I'll leave that for a potential follow-up fix, once the provenance and assumed quality of that original CAIRO_FORMAT_RGB24_888 code is clarified. (I came across this code now with a --without-system-cairo ASan/UBSan Linux build, where JunitTest_toolkit_unoapi_1 failed with > ==1060406==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300146fb48 at pc 0x7fff9b45b338 bp 0x7ffffffef1d0 sp 0x7ffffffef1c8 > READ of size 1 at 0x60300146fb48 thread T0 > Detaching from process 1060652 > #0 in _pixel_to_solid at workdir/UnpackedTarball/cairo/src/cairo-image-source.c:515:207 > #1 in _pixman_image_for_surface at workdir/UnpackedTarball/cairo/src/cairo-image-source.c:1309:22 > #2 in _pixman_image_for_pattern at workdir/UnpackedTarball/cairo/src/cairo-image-source.c:1574:9 > #3 in _cairo_image_source_create_for_pattern at workdir/UnpackedTarball/cairo/src/cairo-image-source.c:1619:2 > #4 in composite_aligned_boxes at workdir/UnpackedTarball/cairo/src/cairo-spans-compositor.c:678:8 > #5 in clip_and_composite_boxes at workdir/UnpackedTarball/cairo/src/cairo-spans-compositor.c:882:11 > #6 in _cairo_spans_compositor_mask at workdir/UnpackedTarball/cairo/src/cairo-spans-compositor.c:999:14 > #7 in _cairo_compositor_mask at workdir/UnpackedTarball/cairo/src/cairo-compositor.c:106:11 > #8 in _cairo_image_surface_mask at workdir/UnpackedTarball/cairo/src/cairo-image-surface.c:952:12 > #9 in _cairo_surface_mask at workdir/UnpackedTarball/cairo/src/cairo-surface.c:2247:14 > #10 in _cairo_gstate_mask at workdir/UnpackedTarball/cairo/src/cairo-gstate.c:1136:11 > #11 in _cairo_default_context_mask at workdir/UnpackedTarball/cairo/src/cairo-default-context.c:993:12 > #12 in cairo_mask at workdir/UnpackedTarball/cairo/src/cairo.c:2283:14 > #13 in SvpSalGraphics::drawAlphaBitmap(SalTwoRect const&, SalBitmap const&, SalBitmap const&) at vcl/headless/svpgdi.cxx:745:5 > #14 in SalGraphics::DrawAlphaBitmap(SalTwoRect const&, SalBitmap const&, SalBitmap const&, OutputDevice const&) at vcl/source/gdi/salgdilayout.cxx:832:16 > #15 in OutputDevice::DrawDeviceAlphaBitmap(Bitmap const&, AlphaMask const&, Point const&, Size const&, Point const&, Size const&) at vcl/source/outdev/bitmap.cxx:704:29 > #16 in OutputDevice::DrawDeviceBitmap(Point const&, Size const&, Point const&, Size const&, BitmapEx&) at vcl/source/outdev/bitmap.cxx:516:9 > #17 in OutputDevice::DrawBitmapEx(Point const&, Size const&, Point const&, Size const&, BitmapEx const&, MetaActionType) at vcl/source/outdev/bitmap.cxx:391:9 > #18 in OutputDevice::DrawBitmapEx(Point const&, Size const&, BitmapEx const&) at vcl/source/outdev/bitmap.cxx:292:9 > #19 in OutputDevice::DrawTransformedBitmapEx(basegfx::B2DHomMatrix const&, BitmapEx const&, double) at vcl/source/outdev/bitmap.cxx:1315:9 > #20 in drawinglayer::processor2d::VclProcessor2D::RenderBitmapPrimitive2D(drawinglayer::primitive2d::BitmapPrimitive2D const&) at drawinglayer/source/processor2d/vclprocessor2d.cxx:394:21 > #21 in drawinglayer::processor2d::VclPixelProcessor2D::processBitmapPrimitive2D(drawinglayer::primitive2d::BitmapPrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:524:5 > #22 in drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:252:13 > #23 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::Primitive2DContainer const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:69:25 > #24 in drawinglayer::processor2d::VclProcessor2D::RenderTransformPrimitive2D(drawinglayer::primitive2d::TransformPrimitive2D const&) at drawinglayer/source/processor2d/vclprocessor2d.cxx:912:5 > #25 in drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:317:13 > #26 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::Primitive2DContainer const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:69:25 > #27 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:46:13 > #28 in drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:434:13 > #29 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::Primitive2DContainer const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:69:25 > #30 in sdr::contact::ObjectContactOfPageView::DoProcessDisplay(sdr::contact::DisplayInfo&) at svx/source/sdr/contact/objectcontactofpageview.cxx:279:31 > #31 in sdr::contact::ObjectContactOfPageView::ProcessDisplay(sdr::contact::DisplayInfo&) at svx/source/sdr/contact/objectcontactofpageview.cxx:116:21 > #32 in SdrPageWindow::RedrawAll(sdr::contact::ViewObjectContactRedirector*) at svx/source/svdraw/sdrpagewindow.cxx:353:28 > #33 in SdrPageView::CompleteRedraw(SdrPaintWindow&, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at svx/source/svdraw/svdpagv.cxx:239:18 > #34 in SdrPaintView::DoCompleteRedraw(SdrPaintWindow&, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at svx/source/svdraw/svdpntv.cxx:606:21 > #35 in SdrPaintView::CompleteRedraw(OutputDevice*, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at svx/source/svdraw/svdpntv.cxx:519:5 > #36 in sd::View::CompleteRedraw(OutputDevice*, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at sd/source/ui/view/sdview.cxx:475:17 > #37 in sd::DrawView::CompleteRedraw(OutputDevice*, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at sd/source/ui/view/drawview.cxx:520:21 > #38 in sd::DrawViewShell::Paint(tools::Rectangle const&, sd::Window*) at sd/source/ui/view/drviews5.cxx:420:17 > #39 in sd::Window::Paint(OutputDevice&, tools::Rectangle const&) at sd/source/ui/view/sdwindow.cxx:212:22 > #40 in PaintHelper::DoPaint(vcl::Region const*) at vcl/source/window/paint.cxx:313:20 > #41 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:616:17 > #42 in PaintHelper::~PaintHelper() at vcl/source/window/paint.cxx:552:30 > #43 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:622:1 > #44 in PaintHelper::~PaintHelper() at vcl/source/window/paint.cxx:552:30 > #45 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:622:1 > #46 in PaintHelper::~PaintHelper() at vcl/source/window/paint.cxx:552:30 > #47 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:622:1 > #48 in PaintHelper::~PaintHelper() at vcl/source/window/paint.cxx:552:30 > #49 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:622:1 > #50 in vcl::Window::PaintImmediately() at vcl/source/window/paint.cxx:1325:24 > #51 in vcl::Window::PaintImmediately() at vcl/source/window/paint.cxx:1269:39 > #52 in SvImpLBox::MyUserEvent(void*) at vcl/source/treelist/svimpbox.cxx:3063:18 > #53 in SvImpLBox::LinkStubMyUserEvent(void*, void*) at vcl/source/treelist/svimpbox.cxx:3057:1 > #54 in Link<void*, void>::Call(void*) const at include/tools/link.hxx:111:45 > #55 in ImplHandleUserEvent(ImplSVEvent*) at vcl/source/window/winproc.cxx:1991:30 > #56 in ImplWindowFrameProc(vcl::Window*, SalEvent, void const*) at vcl/source/window/winproc.cxx:2561:13 > #57 in SalFrame::CallCallback(SalEvent, void const*) const at vcl/inc/salframe.hxx:306:29 > #58 in SvpSalInstance::ProcessEvent(SalUserEventList::SalUserEvent) at vcl/headless/svpinst.cxx:312:22 > #59 in non-virtual thunk to SvpSalInstance::ProcessEvent(SalUserEventList::SalUserEvent) at vcl/headless/svpinst.cxx (instdir/program/libvcllo.so +0xae7a222) > #60 in SalUserEventList::DispatchUserEvents(bool)::$_0::operator()() const at vcl/source/app/salusereventlist.cxx:119:58 > #61 in SalUserEventList::DispatchUserEvents(bool) at vcl/source/app/salusereventlist.cxx:120:13 > #62 in SvpSalInstance::DoYield(bool, bool) at vcl/headless/svpinst.cxx:461:19 > #63 in ImplYield(bool, bool) at vcl/source/app/svapp.cxx:465:48 > #64 in Application::Yield() at vcl/source/app/svapp.cxx:532:5 > #65 in Application::Execute() at vcl/source/app/svapp.cxx:444:9 > #66 in desktop::Desktop::Main() at desktop/source/app/app.cxx:1587:13 > #67 in ImplSVMain() at vcl/source/app/svmain.cxx:198:35 > #68 in SVMain() at vcl/source/app/svmain.cxx:230:12 > #69 in soffice_main at desktop/source/app/sofficemain.cxx:98:12 > #70 in sal_main at desktop/source/app/main.c:49:15 > #71 in main at desktop/source/app/main.c:47:1 > #72 in __libc_start_main at /usr/src/debug/glibc-2.33-8.fc34.x86_64/csu/../csu/libc-start.c:332:16 > #73 in _start at <null> (instdir/program/soffice.bin +0x251acd) > > 0x60300146fb48 is located 0 bytes to the right of 24-byte region [0x60300146fb30,0x60300146fb48) > allocated by thread T0 here: > #0 in operator new[](unsigned long) at ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:102:3 > #1 in ImplCreateDIB(Size const&, vcl::PixelFormat, BitmapPalette const&) at vcl/headless/svpbmp.cxx:126:24 > #2 in SvpSalBitmap::Create(Size const&, vcl::PixelFormat, BitmapPalette const&) at vcl/headless/svpbmp.cxx:156:13 > #3 in Bitmap::Bitmap(Size const&, vcl::PixelFormat, BitmapPalette const*) at vcl/source/bitmap/bitmap.cxx:135:15 > #4 in Bitmap::Crop(tools::Rectangle const&) at vcl/source/bitmap/bitmap.cxx:489:20 > #5 in BitmapEx::Crop(tools::Rectangle const&) at vcl/source/bitmap/BitmapEx.cxx:360:25 > #6 in drawinglayer::primitive2d::DiscreteShadow::getLeft() const at drawinglayer/source/primitive2d/discreteshadowprimitive2d.cxx:148:61 > #7 in drawinglayer::primitive2d::DiscreteShadowPrimitive2D::create2DDecomposition(drawinglayer::primitive2d::Primitive2DContainer&, drawinglayer::geometry::ViewInformation2D const&) const at drawinglayer/source/primitive2d/discreteshadowprimitive2d.cxx:251:72 > #8 in drawinglayer::primitive2d::BufferedDecompositionPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor&, drawinglayer::geometry::ViewInformation2D const&) const at drawinglayer/source/primitive2d/baseprimitive2d.cxx:122:9 > #9 in drawinglayer::primitive2d::DiscreteMetricDependentPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor&, drawinglayer::geometry::ViewInformation2D const&) const at drawinglayer/source/primitive2d/primitivetools2d.cxx:48:47 trying to read the fourth byte of a presumed uint32_t starting at offset 21 of a 24-byte buffer.) Change-Id: Ibe8bc39e3736c64ace61af2217100c9d8bb96d5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116637 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-01cairo: just register and use external fontconfigJan-Marek Glogowski
Except for the pixman include, the ANDROID cairo external is the same then the other OS use. It also builds fontconfig, so there is really no need to depend on the source (ok, this way it can be a bit more parallel, if nothing is generated). But the build nevertheless always sets includes for fontconfig anyway. And the code implied you can build Android without --disable-dynloading. Change-Id: I9970dc5c052b6fa80588233244c6828079d8277e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116554 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-06-01cairo: Drop config for WNT and MACOSX buildJan-Marek Glogowski
It's not used on these platforms since a long time. Change-Id: Idac41f1be0a546fd8aa0dd88709ebfa3255a104e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116555 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-05-28crashtesting: backport assert downgradeCaolán McNamara
Change-Id: I6d813cd9996633b207e30c2f1fff707810396153 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116315 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-05-25upgrade to Expat 2.4.1Caolán McNamara
drop ubsan patch in favour of fix applied as https://github.com/libexpat/libexpat/pull/398 Change-Id: I59eb9e24206b9a4cf323b7f7d48d8df0792a1c46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116092 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-05-21libxml2: upgrade to release 2.9.12Michael Stahl
Fixes: CVE-2021-3516 CVE-2021-3517 CVE-2021-3518 CVE-2021-3537 CVE-2021-3541 * external/libxml2/ubsan.patch.0: remove, fixed upstream Change-Id: I347dc854b862e78bde87d3e57cf5fdb584ca5673 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115913 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-05-20upload libetonyek 0.1.10David Tardon
Change-Id: Iad586802e89b19701a20bebff06b238b617af2a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115769 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2021-05-14Change one more <Carbon/Carbon.h> to <CoreGraphics/CoreGraphics.h>Tor Lillqvist
Change-Id: Ib8ed1e4270b18de4761155f9aa7d536faaf7bd38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115581 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-05-12Update to ICU 69.1Eike Rathke
Change-Id: I32836175a877349777dcbb6eb7b0d813aa31199a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115479 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-05-12external: update pdfium to 4500Miklos Vajna
Change-Id: I38c85fb3e30ffd1f7fc0a11948fc01338f7bb205 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115444 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-05-10upload libmwaw 0.3.19David Tardon
Change-Id: Ibb26390e6cc13c925f499bf95cfc6177d8c9b735 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115355 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2021-05-07external/python3: Mark configure part of darwin.patch.0 as reported upstreamStephan Bergmann
Change-Id: Ibf9fb088eb1d7e11582518aeafa233dfa7c56bf6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115223 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-07external/python3: Clang 13 trunk implements --print-multiarch nowStephan Bergmann
...since <https://github.com/llvm/llvm-project/commit/a921d2d2fb46b898794091e7410426c518a4f0cc> "[Driver] Add -print-multiarch", which causes an issue when building ExternalProject_python3 on macOS: > checking build system type... x86_64-apple-darwin19.6.0 > checking host system type... x86_64-apple-darwin19.6.0 [...] > checking for the platform triplet based on compiler characteristics... darwin configure: error: internal configure error for the platform triplet, please file a bug report > make[1]: *** [/Users/stephan/Software/lo/core/external/python3/ExternalProject_python3.mk:80: /Users/stephan/Software/lo/core/workdir/ExternalProject/python3/build] Error 1 as workdir/UnpackedTarball/python3/configure.ac computes PLATFORM_TRIPLET as "darwin", and instead of computing MULTIARCH as empty (as `$CC --print-multiarch` used to just print > clang: error: unsupported option '--print-multiarch' > clang: error: no input files to stderr), it now computes it as e.g. "x86_64-apple-darwin19.6.0" (or whatever -target is explicitly set to in $CC), so the check that they have equal values if they are bot nonempty fails now when building against Clang 13 trunk. (This is not yet an issue with any Apple Clang version, though.) Until this is eventually fixed upstream at <https://github.com/python/cpython>, just keep pretending that `clang --print-multiarch` would cause no stdout output on macOS when determining MULTIARCH. Change-Id: Ic1b27c6791b327d5709a9d61a6d675c3fa8989bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115219 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-07external/python3: First removeunnecessarystuff, then fixinstallnamesStephan Bergmann
otherwise, we could get issues like > error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: /Users/stephan/Software/lo/core/workdir/UnpackedTarball/python3/python-inst/@__________________________________________________OOO/LibreOfficePython.framework/Versions/3.8/lib/python3.8/lib-dynload/_curses_panel.cpython-3.8.so (No such file or directory) > error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: /Users/stephan/Software/lo/core/workdir/UnpackedTarball/python3/python-inst/@__________________________________________________OOO/LibreOfficePython.framework/Versions/3.8/lib/python3.8/lib-dynload/_curses.cpython-3.8.so (No such file or directory) > error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: /Users/stephan/Software/lo/core/workdir/UnpackedTarball/python3/python-inst/@__________________________________________________OOO/LibreOfficePython.framework/Versions/3.8/lib/python3.8/lib-dynload/_testinternalcapi.cpython-3.8.so (No such file or directory) > error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: /Users/stephan/Software/lo/core/workdir/UnpackedTarball/python3/python-inst/@__________________________________________________OOO/LibreOfficePython.framework/Versions/3.8/lib/python3.8/lib-dynload/_dbm.cpython-3.8.so (No such file or directory) when the two jobs run in parallel Change-Id: I6db18d7a6fa0ce177e88f8f714434acf9afe3ea5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115218 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-06pdfium build fix with Android NDK 19Andras Timar
Change-Id: I618095efab0a7ed7babdabc36db6a473b1af78da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115161 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com> (cherry picked from commit 01765acee6b4931b6c69252b8357f81fd26e33bd) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115090 Tested-by: Jenkins
2021-05-05WASM: add initial support for Emscripten cross buildJan-Marek Glogowski
- configure with: - --host=wasm64-local-emscripten - had to make a few externals optional, so adding: - --disable-nss - --disable-cmis - --disable-curl Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-05-05Switch OPENSSL config var from negative to positiveJan-Marek Glogowski
- align with most of the rest of config_host - rename DISABLE_OPENSSL to ENABLE_OPENSSL - make this configurable Change-Id: Ic3b41fcdda38db66134939f12265e0da24833d60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114564 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-05-03liborcus,zxing: add link to GCC bugMichael Stahl
Change-Id: I9420e786c4050a9ae79f1deab76a43e62c3b15fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115031 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-05-03update breakpad to the current chrome_m90 snapshotLuboš Luňák
We've been using a version from 2015. And it appears that most (all?) crashreports generated on Windows have unusable backtraces, so maybe this update helps with that. Change-Id: Ied4a7943e6023c625bcd9060f18b4b90c00ad29b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113750 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-05-01liborcus: newline problem with GCC 11 -E -fdirectives-onlyMichael Stahl
ooxml_tokens.inl:3524:32: error: stray '#' in program Change-Id: Ib7f50e1798e8c985f31a0338944ae1e9b439e98f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114975 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-05-01zxing: newline problem with GCC 11 -E -fdirectives-onlyMichael Stahl
KRHangulMapping.h:38:55: error: stray '#' in program Change-Id: I81e15f524c68da6bd5271a89035857f5e3c2ebc3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114974 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-04-30serf should use bundled openssl headers, not system openssl headersAndras Timar
Change-Id: I4431e5141a80394950f5711051065df42fe85f8d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114934 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-04-30allow utf-8 in xml names (liborcus) (tdf#141672)Luboš Luňák
Change-Id: Ib150d55b588a572e4352396f18de2331983b2aae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114892 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-30external: update libxmlsec to 1.2.32Miklos Vajna
And drop the 2 upstreamed patches. Change-Id: Ia821023d9cc06df5e9e7aef82c070ad1c98b67e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114894 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-04-28Resolves tdf#141553 - Update David CLM fontHeiko Tietze
Culmus font 0.131 updated to 0.133 Change-Id: Icd79dbef8dc350362ea4c4a7ed2ff05a1b95a1a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114738 Reviewed-by: Hossein <hossein.ir@gmail.com> Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org> Tested-by: Jenkins
2021-04-21Python .so files names have changed on macOS at least for some reasonTor Lillqvist
There is no longer any "m" in the name suffix. Adapt the names of the ones we want to remove for macOS. The idlelib and tkinter dylibs are no longer there at all. Don't use the -f flag to the rm commands. Thus we will notice the next time something we want to remove isn't actually there or has been renamed. But sadly for some unknown reason we do need to use a * wildcard in the .so names. Fixes a problem caught by App Store review where the Python curses module had not been removed as it should have been. (It uses non-public APIs and can thus not be included.) Change-Id: I51b9728cc9ca0a962908d3994e3a0ff8e4fa7f60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114372 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-04-15fix serf dependenciesLuboš Luňák
RepositoryExternal.mk treats apr and apr_util as one external, but technically they are two, so both of it must be built for 'apr' to be ready to be used by serf. Change-Id: If00fb10a698fd926437e18ac0e4fa66b2722ebae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114135 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-14update serf to 1.3.9Luboš Luňák
Its build system has switches to scons, so build the library using gbuild. Change-Id: I45b784e65e4987c25baf3fa1477816c744663bf0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114107 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-14Revert "update Skia to chrome/m91" (tdf#141680)Luboš Luňák
The m91 snapshot seems to cause a number of Vulkan problems. My commit already worked around one, but there are apparently others, such as very slow startup, or a failed Skia assertion triggered by VCL Skia's copyArea(). This reverts commit 09d850e46903a528d4b08d3fdf03c3964d79fbc5. Change-Id: I4f1832ba76db15cab8eccbe115d21c989da3c841 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114089 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-13external/jfreereport: Get rid of remaining apache-commons-loggingStephan Bergmann
...similar to b721a1cecb6ea0013be8402350110822e50b4415 "external/jfreereport: Get rid of apache-commons-logging", but where the external tarballs contain copies of commons-logging-api-1.0.4.jar to compile against, so 6de0b1710adfba82c96b75a5da6f52633a54c692 "Get rid of apache-commons-logging" did not affect them at build- but only at run-time. The sources of the seven new patch files (and which have further been adapted as necessary) are taken from <https://src.fedoraproject.org/rpms/libbase/blob/4a8cd85e49a0a00d0e0f865a3c841e3f1858a04b> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging", <https://src.fedoraproject.org/rpms/libfonts/c/c7f7d4ed67b9ca701152732cbdac547db3ada5f4> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging", <https://src.fedoraproject.org/rpms/libformula/c/feb5be4b393f13b131623339a5868c6b381b2507> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging", <https://src.fedoraproject.org/rpms/libloader/c/53eeb19460f2ab934cdf4c7c7c73fd681141216c> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging", <https://src.fedoraproject.org/rpms/librepository/c/9fa7021dfe7dcc76e32c40f99f74c3745013c501> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging", <https://src.fedoraproject.org/rpms/libserializer/c/027e1a16f7171f7ac5f9da4683d1e1b63794bb06> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging", and <https://src.fedoraproject.org/rpms/pentaho-libxml/c/74538ea7cdd0845f8e6dff748f8d4abfe080dbe4> "add missing patch". Change-Id: I98bbe0e24398d3652cda09b0664b4775661cd939 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114053 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-12update Skia to chrome/m91Luboš Luňák
Change-Id: I82050e9695b9aa49c33ee16d345bb64595b00bbc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113978 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
generated by cgit (git 2.34.1) at 2024-07-15 12:40:10 +0000