summaryrefslogtreecommitdiff
path: root/external/liborcus
AgeCommit message (Collapse)Author
2023-02-11Update liborcus to 0.18.1Kohei Yoshida
Change-Id: I0439640789e59e4dd6e92d7f2975538de2f42f53 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146826 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2023-01-26Just use std::variant and std::getKohei Yoshida
Change-Id: If467225fae07a9d33e324cac9ff32300d6c56534 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146151 Tested-by: Kohei Yoshida <kohei@libreoffice.org> Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2023-01-26Upgrade mdds and orcus to 2.1.0 and 0.18.0, respectivelyKohei Yoshida
Change-Id: I288b5b54bd07d951bcc68afda7514bde730193dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146107 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2023-01-17Don't bother building the liborcus benchmarkTor Lillqvist
It causes a problem when building with Emscripten and --enable-wasm-exceptions. Instead of fixing that problem, just don't bother building executables we won't run anyway. (Ideally liborcus should have some --disable-benchmark configure options, ping Kohei.) Change-Id: Ic8c1d51513793bba85dc2833cc8fd9ec5b97ce76 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145645 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2022-10-14WASM add Calc as optional build result, make it build & runBalazs Varga
Adding new config option: --with-main-module=<writer/calc> With this switcher we can build only WASM writer module or calc module. The default value is 'writer'. This commit also reverts: 26603bc9ef0116ed31c510dab82b69d3666447b5 (WASM fix orcus native exception handling (NEH)) Because Calc import is using liborcus for loading styles.xml. Change-Id: I4c330ef8eea7d08214bf357531ee0bf7383ab788 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137946 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Tested-by: Jenkins
2022-08-04tdf#150247: patch orcus to use UTF-16 paths on WindowsMike Kaganski
This adds UTF8->UTF16 conversion of the paths passed to ctor of file_content on Windows, since both boost::filesystem::file_size and boost::interprocess::file_mapping take UTF-16 strings on this platform. So the assumption is that 8-bit path strings passed to orcus are UTF-8-encoded. This partially reverts commit 75252e58d9b5d020bf7bd6ca66b3a9d780463051 (it keeps use of osl_getThreadTextEncoding for platforms other than Windows). Change-Id: Ie467f71a65945f4f07ff432136ea06b811c3f794 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137759 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-06-28Fix typoStephan Bergmann
...that was present since 173214d92046b4ea11f6c0959ca40999d1e0bbd2 "Fix liborcus build for Android" (but doesn't seem to have caused issues all those years) Change-Id: I70161f20a94655e8f485cd49bec9ce461c7507f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136563 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-06-27Mark external/liborcus/overrun.patch.0 as upstreamedStephan Bergmann
Change-Id: Ibc77db49c7b584df1f5f3c086ecd479a28eb7797 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136484 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-06-24external/liborcus: Fix heap-buffer-overflowStephan Bergmann
...as seen during CppunitTest_vcl_pdfexport: > ==573913==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62b0001dba0e at pc 0x560576627186 bp 0x7ffeab9fa730 sp 0x7ffeab9f9ef0 > READ of size 26624 at 0x62b0001dba0e thread T0 > #0 in StrtolFixAndCheck(void*, char const*, char**, char*, int) at ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:3629:3 > #1 in strtol at ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:485:3 > #2 in orcus::sax_token_handler_wrapper_base::attribute(std::basic_string_view<char, std::char_traits<char>>, std::basic_string_view<char, std::char_traits<char>>) at workdir/UnpackedTarball/liborcus/src/parser/sax_token_parser.cpp:344:22 > #3 in orcus::sax_ns_parser<orcus::sax_token_parser<orcus::xml_stream_handler>::handler_wrapper>::handler_wrapper::attribute(orcus::sax::parser_attribute const&) at workdir/UnpackedTarball/liborcus/src/liborcus/../../include/orcus/sax_ns_parser.hpp:212:27 > #4 in orcus::sax_parser<orcus::sax_ns_parser<orcus::sax_token_parser<orcus::xml_stream_handler>::handler_wrapper>::handler_wrapper, orcus::sax_parser_default_config>::attribute() at workdir/UnpackedTarball/liborcus/src/liborcus/../../include/orcus/sax_parser.hpp:570:15 > #5 in orcus::sax_parser<orcus::sax_ns_parser<orcus::sax_token_parser<orcus::xml_stream_handler>::handler_wrapper>::handler_wrapper, orcus::sax_parser_default_config>::declaration(char const*) at workdir/UnpackedTarball/liborcus/src/liborcus/../../include/orcus/sax_parser.hpp:389:9 > #6 in orcus::sax_parser<orcus::sax_ns_parser<orcus::sax_token_parser<orcus::xml_stream_handler>::handler_wrapper>::handler_wrapper, orcus::sax_parser_default_config>::element() at workdir/UnpackedTarball/liborcus/src/liborcus/../../include/orcus/sax_parser.hpp:242:13 > #7 in orcus::sax_parser<orcus::sax_ns_parser<orcus::sax_token_parser<orcus::xml_stream_handler>::handler_wrapper>::handler_wrapper, orcus::sax_parser_default_config>::body() at workdir/UnpackedTarball/liborcus/src/liborcus/../../include/orcus/sax_parser.hpp:214:13 > #8 in orcus::sax_parser<orcus::sax_ns_parser<orcus::sax_token_parser<orcus::xml_stream_handler>::handler_wrapper>::handler_wrapper, orcus::sax_parser_default_config>::parse() at workdir/UnpackedTarball/liborcus/src/liborcus/../../include/orcus/sax_parser.hpp:182:5 > #9 in orcus::sax_ns_parser<orcus::sax_token_parser<orcus::xml_stream_handler>::handler_wrapper>::parse() at workdir/UnpackedTarball/liborcus/src/liborcus/../../include/orcus/sax_ns_parser.hpp:277:14 > #10 in orcus::sax_token_parser<orcus::xml_stream_handler>::parse() at workdir/UnpackedTarball/liborcus/src/liborcus/../../include/orcus/sax_token_parser.hpp:215:14 > #11 in orcus::xml_stream_parser::parse() at workdir/UnpackedTarball/liborcus/src/liborcus/xml_stream_parser.cpp:68:9 > #12 in orcus::orcus_xls_xml::detect(unsigned char const*, unsigned long) at workdir/UnpackedTarball/liborcus/src/liborcus/orcus_xls_xml.cpp:94:16 > #13 in orcus::detect(unsigned char const*, unsigned long) at workdir/UnpackedTarball/liborcus/src/liborcus/format_detection.cpp:68:9 > #14 in (anonymous namespace)::OrcusFormatDetect::detect(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&) at sc/source/filter/orcus/filterdetect.cxx:83:31 > 0x62b0001dba0e is located 0 bytes to the right of 26638-byte region [0x62b0001d5200,0x62b0001dba0e) > 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:98:3 > #1 in SvMemoryStream::AllocateMemory(unsigned long) at tools/source/stream/stream.cxx:1698:12 > #2 in SvMemoryStream::SvMemoryStream(unsigned long, unsigned long) at tools/source/stream/stream.cxx:1544:9 > #3 in (anonymous namespace)::OrcusFormatDetect::detect(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&) at sc/source/filter/orcus/filterdetect.cxx:71:20 This started to occur now after a95c585433246813096e8890b7ed6ef4fe30c621 "Pump XInputStream into an SvMemoryStream rather than an OStringBuffer" no longer guarantees that the memory range passed into orcus::detect(const unsigned char* buffer, size_t length) is followed by a null byte at buffer[length]. (There appears to be no documentation for that function, but it looks unreasonable to me that it should require callers to provide a buffer thus terminated, and I rather assume that what is observed here is an orcus bug.) The problematic calls of std::strtol were used in code apparently meant to parse strings matching the XML VersionNum grammar production, and then store the two dot-separated numbers each as uint8_t. The new code using a local readUint8 accepts a different set of strings now than the original code using std::strtol, but the new set is arguably closer to what the actual XML VersionNum grammar production accepts (which is '1.' [0-9]+ for XML 1.0 and '1.1' for XML 1.1), so this change should be OK. Change-Id: I1668542c96ced64667cb9f251e79126e1a54ac30 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136405 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-05-23Missing #include <stdint.h> in various external codeStephan Bergmann
...which is a problem presumably since GCC 13 trunk <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6f038efd93593da6e661b829d1bd3877e75550f1> "libstdc++: Avoid including <cstdint> for std::char_traits". (All the broken C++ code used unqualified uintptr_t etc. rather than std::uintptr_t etc., so I deemed it more appropriate to include <stdint.h> rather than <cstdint>.) Change-Id: Id9dfc383c5986126a425971c4557b90ac45ac963 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134760 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-05-01try to use also proper debug LDFLAGS for externals librariesLuboš Luňák
This is basically ea68de2968c0dbcd8e7549435e829db06795c16d but for LDFLAGS. A number of external libs cannot use this because their libtool mishandles -fuse-ld. Change-Id: Idee379eb0a3afb475b536519ee3de064b4e218f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133639 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-30forcepoint#95 read past end of malformed documentCaolán McNamara
Change-Id: I8b2c558c733af3d7662f668af47e962e252ee339 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132311 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-25forcepoint#88 temp std::string assigned to std::string_viewCaolán McNamara
Change-Id: I128a60b68a3af988e3a4bdb06994f43d9b18d67e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132102 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-25forcepoint#87 Assertion 'mp_char <= mp_end' failedCaolán McNamara
Change-Id: I434928cb2425a2e8eb9440dff67f52cda241b2d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132097 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-24forcepoint#83 forcepoint#84 update to upstream fixCaolán McNamara
Change-Id: I5add09b4379a1f86a720af75b758389424f4f50b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132055 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-24forcepoint#84 Invalid read of size 1Caolán McNamara
Change-Id: I1d0d74940cfa78a3c88cee737c9535acf03e0f19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131991 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-23forcepoint#83 Invalid read of size 1Caolán McNamara
Change-Id: I1576dfd8c9731d943107764aeb66bb1c2294ad5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131983 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-02-20WASM fix orcus native exception handling (NEH)Jan-Marek Glogowski
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>
2022-01-31externals: always provide platform configure flagsJan-Marek Glogowski
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>
2021-12-16Update liborcus to 0.17.2.Kohei Yoshida
Change-Id: I76c0d57da63c1e35f80b13071793dbbb27cb218a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126655 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2021-11-17crashtesting: crash on passing null to std::string_viewCaolán McNamara
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>
2021-11-04Consolidate -D_GLIBCXX_DEBUG for --enable-dbgutil builds against libstdc++Stephan Bergmann
(this was meant as a prerequisite for enabling its -D_LIBCPP_DEBUG=1 counterpart when building against libc++ on macOS, but which got stalled for now after running into the issue described at <https://lists.llvm.org/pipermail/libcxx-dev/2021-October/001222.html> "[libcxx-dev] Building a program with -D_LIBCPP_DEBUG=1 against a libc++ that is not itself built with that define") Change-Id: If466dce595a9311b2afbae41d5ddcaecc6f3c57b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124678 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-03Upgrade mdds and liborcus to 2.0.0 and 0.17.0, respectively.Kohei Yoshida
Change-Id: I9e856fc2d61f1789a6f1702514837860539a0f49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124573 Tested-by: Jenkins Tested-by: René Engelhard <rene@debian.org> Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
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-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-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-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>
2020-10-08external/liborcus: Missing includesStephan Bergmann
...as seen with recent GCC 11 trunk libstdc++: > orcus_xlsx.cpp: In function ‘size_t orcus::{anonymous}::get_schema_rank(orcus::schema_t)’: > orcus_xlsx.cpp:313:59: error: incomplete type ‘std::numeric_limits<long unsigned int>’ used in nested name specifier > 313 | return it == rank_map.end() ? numeric_limits<size_t>::max() : it->second; > | ^~~ etc. Change-Id: If92cfb565ed9344b2ec1403793d7aeff8bd019ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104074 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-29Update liborcus to 0.16.1.Kohei Yoshida
Change-Id: I27e87278545c1d41381b1ab8a49f6f6a07681bfb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103590 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2020-09-21update pchesCaolán McNamara
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-12Remove unused patches.Kohei Yoshida
Change-Id: I2a1dbe15f2df42b4f74e0c00b91ace6c0d3f5f8e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102503 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2020-09-12Upgrade liborcus to 0.16.0.Kohei Yoshida
Change-Id: Iae29fb26417dfc161698a81bee84e81545969065 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102502 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2020-07-28Adapt --enable-ld to Clang 12 trunk --ld-pathStephan Bergmann
...split from -fuse-ld with <https://github.com/llvm/llvm-project/commit/ 1bc5c84710a8c73ef21295e63c19d10a8c71f2f5> "[Driver] Add --ld-path= and deprecate -fuse-ld=/abs/path and -fuse-ld=rel/path", and now causing warnings (or even errors with -Werror) like '-fuse-ld=' taking a path is deprecated. Use '--ld-path=' instead when --enable-ld is configured as a full path. (--enable-ld was vague whether it supports full paths, but it appeared to work reasonably well at least with old versions of Clang.) Change-Id: I5a7dfd992b56aba78dd3646045fb9a827dc40321 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99569 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-16GBUILD_TRACE, support for finding out where the build time is spentLuboš Luňák
See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-02-01make update_pch also consider files in <module>/src/**/incLuboš Luňák
With --enable-pch=full there's not much difference between a "public" header in <module>/inc and a private one in <module>/src/somewhere/inc . And since the script searches recursively, this apparently helps to find even more headers for lower pch levels. Change-Id: I8483d0aa5b4fea5a59107c20a8aa5f1ef694af0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87799 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-14add PCHs for more external libsLuboš Luňák
I think this is all external libs where it makes sense for them to have their own PCH and be worth it. Maybe some smaller externals can also use the common system PCH, but unfortunately many externals use all kinds of defines that affect system headers, which is a problem for the common system PCH. Change-Id: I2c589ac55d93728daf3b158df110722e5f055d45 Reviewed-on: https://gerrit.libreoffice.org/80728 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-08-29Update commentStephan Bergmann
external/liborcus/0001-Blind-fix-attempt-for-older-macOS-builds.patch has been removed with df2b4a9daa643e66b705a7b39d8988a3d97d731e "Update liborcus to 0.15.2." Change-Id: I1014e1ff847468b5b6c05ee363c1e6017722fd47 Reviewed-on: https://gerrit.libreoffice.org/78271 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-29Update liborcus to 0.15.2.Kohei Yoshida
Change-Id: I1a16e7ba9a096862933536268dacf5ab49476896 Reviewed-on: https://gerrit.libreoffice.org/78246 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2019-08-27Record patch as upstreamedStephan Bergmann
Change-Id: Ib28e86de29cdb5d91e05b341c75b87590e8b3aa6 Reviewed-on: https://gerrit.libreoffice.org/78189 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-23external/liborcus: Blind fix attempt for older macOS builds, take 3Stephan Bergmann
One more place that needs a workaround like 5c2c08f635c30b732df48faca7ba3d411074e05a "external/liborcus: Blind fix attempt for older macOS builds" and ee02218eb9aaa36f37619cb16bb389762e1785b2 "external/liborcus: Blind fix attempt for older macOS builds, take 2". Change-Id: I330737e1c31744cd28f753f18edf9c911946b37c Reviewed-on: https://gerrit.libreoffice.org/78022 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-08-23external/liborcus: Blind fix attempt for older macOS builds, take 2Stephan Bergmann
More places that need a workaround like 5c2c08f635c30b732df48faca7ba3d411074e05a "external/liborcus: Blind fix attempt for older macOS builds". Change-Id: Idcdfbddabac63bcc778a43ce5dfbf6b9f70d20e1 Reviewed-on: https://gerrit.libreoffice.org/78008 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-23external/liborcus: Blind fix attempt for older macOS buildsStephan Bergmann
see external/liborcus/0001-Blind-fix-attempt-for-older-macOS-builds.patch for details Change-Id: I7be71524da1cf702218170fd2c921d35c176ea4c Reviewed-on: https://gerrit.libreoffice.org/77997 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-23Update commentStephan Bergmann
external/liborcus/create-element.patch.0 has been removed with 52800fd6d9867252b795b6afacce19f66b5a5107 "Update orcus to 0.15.1." Change-Id: Ie127466778f9c15c8edd9de8511c3f60f6da1cd7 Reviewed-on: https://gerrit.libreoffice.org/77988 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-23Update orcus to 0.15.1.Kohei Yoshida
Change-Id: Ifd945d03719bf2ed1fb145b405f1ea9297ebeb68 Reviewed-on: https://gerrit.libreoffice.org/77983 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2019-08-16Record external/liborcus/create-element.patch.0 as covered upstreamStephan Bergmann
Change-Id: Ib1b1baf75cbd2d011e96a3d5b8876a6b356b0b7e Reviewed-on: https://gerrit.libreoffice.org/77536 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-15external/liborcus/version.patch.0 is goneStephan Bergmann
...since 56ffe3c0a1261cd98a3d42b8b08d5f8eb013ead4 "Switch mdds to 1.5.0 and liborcus to 0.15.0." Change-Id: I03c5336bbaf65a13f883a30a3fc4238b140a9cef Reviewed-on: https://gerrit.libreoffice.org/77521 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-15Fix linking of newly created element in liborcus 0.15.0Stephan Bergmann
After 56ffe3c0a1261cd98a3d42b8b08d5f8eb013ead4 "Switch mdds to 1.5.0 and liborcus to 0.15.0", CppunitTest_sc_dataprovider started to fail in ASan builds with > ERROR: AddressSanitizer: new-delete-type-mismatch on 0x6060005b9340 in thread T4 (XML Fetch Threa): > object passed to delete has wrong type: > size of the allocated type: 56 bytes; > size of the deallocated type: 16 bytes. > #0 in operator delete(void*, unsigned long) at llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:172:3 > #1 in orcus::xml_map_tree::element::~element() at workdir/UnpackedTarball/liborcus/src/liborcus/xml_map_tree.cpp:238:13 [...] > #25 in std::unique_ptr<orcus::orcus_xml::impl, std::default_delete<orcus::orcus_xml::impl> >::~unique_ptr() > #26 in orcus::orcus_xml::~orcus_xml() at workdir/UnpackedTarball/liborcus/src/liborcus/orcus_xml.cpp:530:26 > #27 in ScOrcusXMLContextImpl::importXML(ScOrcusImportXMLParam const&) at sc/source/filter/orcus/xmlcontext.cxx:286:5 [...] > 0x6060005b9340 is located 0 bytes inside of 56-byte region [0x6060005b9340,0x6060005b9378) > allocated by thread T4 (XML Fetch Threa) here: > #0 in operator new(unsigned long) at llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:99:3 > #1 in orcus::xml_map_tree::element::element(char const*, orcus::pstring const&, orcus::xml_map_tree::element_type, orcus::xml_map_tree::reference_type) at workdir/UnpackedTarball/liborcus/src/liborcus/xml_map_tree.cpp:203:26 > #2 in std::unique_ptr<orcus::xml_map_tree::element, std::default_delete<orcus::xml_map_tree::element> > orcus::make_unique<orcus::xml_map_tree::element, char const*&, orcus::pstring, orcus::xml_map_tree::element_type, orcus::xml_map_tree::reference_type>(char const*&, orcus::pstring&&, orcus::xml_map_tree::element_type&&, orcus::xml_map_tree::reference_type&&) at workdir/UnpackedTarball/liborcus/src/liborcus/../../include/orcus/global.hpp:61:35 > #3 in orcus::xml_map_tree::element::get_or_create_child(orcus::string_pool&, char const*, orcus::pstring const&) at workdir/UnpackedTarball/liborcus/src/liborcus/xml_map_tree.cpp:271:9 > #4 in orcus::xml_map_tree::get_linked_node(orcus::pstring const&, orcus::xml_map_tree::reference_type) at workdir/UnpackedTarball/liborcus/src/liborcus/xml_map_tree.cpp:722:31 [...] Change-Id: Iad8e06ead6f2655a3e26ceeab368e9b50028402f Reviewed-on: https://gerrit.libreoffice.org/77519 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-15Switch mdds to 1.5.0 and liborcus to 0.15.0.Kohei Yoshida
Change-Id: Ibff9a5e0f0771e4cf12b4dc3985661a01195e265 Reviewed-on: https://gerrit.libreoffice.org/77482 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2019-05-24disable warnings in external libsLuboš Luňák
As in, really disable, so that they do not even show. This moreover avoids tons of D9025 warnings from MSVC about overriding -W4 with -w. Change-Id: Ia2e72fd72d883d91bdd89e467ee42f259e2ae033 Reviewed-on: https://gerrit.libreoffice.org/72899 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-05-06enable gdb-index also for liborcus and libwps if possibleLuboš Luňák
These are larger C++ libs and without gdb-index gdb takes a moment to load such libs. Change-Id: I555a629199f761060199a528415f7d5fbe9d9533 Reviewed-on: https://gerrit.libreoffice.org/71822 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
generated by cgit (git 2.34.1) at 2025-02-03 20:46:43 +0000