Age | Commit message (Collapse) | Author |
|
...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>
(cherry picked from commit 3f17a643d0f943d02c7cb2b5d8e702fe0e63e38d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136417
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
(cherry picked from commit 1e51a325a8e21eb5f900336a0c9e1bd78ed330ab)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136163
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8b2c558c733af3d7662f668af47e962e252ee339
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132311
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 0b9892fee990b7f6d0457ab6191f87c3991580e6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132409
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I128a60b68a3af988e3a4bdb06994f43d9b18d67e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132102
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 87259aef31a0411ccc8cb045ceb1365c23e917e5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132408
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I434928cb2425a2e8eb9440dff67f52cda241b2d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132097
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 32019baffa19a8f79cacf93d5dd5a95c7d416657)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132407
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I5add09b4379a1f86a720af75b758389424f4f50b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132055
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 2323fa29617e4919226517d50abbb9ad33b320ca)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132406
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1d0d74940cfa78a3c88cee737c9535acf03e0f19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131991
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit d6a02a99eaa3690c0aa5c33fea3a4c710813a0de)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132188
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I1576dfd8c9731d943107764aeb66bb1c2294ad5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131996
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I76c0d57da63c1e35f80b13071793dbbb27cb218a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126655
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
(cherry picked from commit aadbac5467bb6ab768f87ed6ec003c55159d54aa)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126886
|
|
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>
|
|
(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>
|
|
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>
|
|
- 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>
|
|
Change-Id: I9420e786c4050a9ae79f1deab76a43e62c3b15fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115031
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
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>
|
|
Change-Id: Ib150d55b588a572e4352396f18de2331983b2aae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114892
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
...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>
|
|
Change-Id: I27e87278545c1d41381b1ab8a49f6f6a07681bfb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103590
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I2a1dbe15f2df42b4f74e0c00b91ace6c0d3f5f8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102503
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
Change-Id: Iae29fb26417dfc161698a81bee84e81545969065
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102502
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
...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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: I1a16e7ba9a096862933536268dacf5ab49476896
Reviewed-on: https://gerrit.libreoffice.org/78246
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
Change-Id: Ib28e86de29cdb5d91e05b341c75b87590e8b3aa6
Reviewed-on: https://gerrit.libreoffice.org/78189
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Ifd945d03719bf2ed1fb145b405f1ea9297ebeb68
Reviewed-on: https://gerrit.libreoffice.org/77983
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
Change-Id: Ib1b1baf75cbd2d011e96a3d5b8876a6b356b0b7e
Reviewed-on: https://gerrit.libreoffice.org/77536
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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>
|
|
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>
|
|
Change-Id: Ibff9a5e0f0771e4cf12b4dc3985661a01195e265
Reviewed-on: https://gerrit.libreoffice.org/77482
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
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>
|
|
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>
|
|
It had been left out in 4082a18406c18af7b4fcef7bd501c3679c3be56b "android: use
unified headers and llvm-c++ STL (x86) with NDK 16" because "arm unfortunately
crashes with llvm-c++, so keep with gnustl for now/fix that later".
Making armeabi-v7a work with libc++ etc. required a number of changes, listed
below, in this commit and in preceding ones. At least 32-bit x86 already worked
with libc++ etc. prior to these changes in view mode, though it crashed in the
experimental editing mode (enabled with strippedUIEditing in
android/soruce/Makefile) as soon as one types in something, But it is not
entirely clear to me why 32-bit x86 view mode didn't also fail similar to how I
saw armeabi-v7a fail. (On 32-bit x86, these changes appear to neither improve
nor worsen the current state, view mode still appears to work fine while editing
still crashes upon typing anything. With these changes, editing mode on
armeabi-v7a appears to work fine. But I tested armeabi-v7a only with a real
device and 32-bit x86 only with an emulator, in case that might make a
difference.)
* Preceding <https://gerrit.libreoffice.org/#/c/64964/> "Move NSSLIBS to a more
sensible place on the linker command line" plus this change's addition of
-lunwind to the liblo-native-code.so linker command line make sure that
liblo-native-code.so uses _Unwind_* functions from libunwind.a, instead of
erroneously picking up the ones from libgcc.a that happen to be included in
NSSLIB's nspr4 (-lgcc is automatically added to the end of the linker command
line by the invoking compiler, that's how libgcc.a's _Unwind_* end up in
NSSLIB's nspr4; it is neither clear to me why NSSLIB's nspr4, being a pure C
library, uses _Unwind_* functions, nor why exception handling in
liblo-native-code.so fails when using _Unwind_* functions from libgcc.a
instead of from libunwind on armeabi-v7a, nor why that would work on 32-bit
x86, but that's what I observed: ModuleManager::identify
(framework/source/services/modulemanager.cxx) throws a
css::lang::IllegalArgumentException, which calls __cxa_throw ->
_Unwind_RaiseException, which ultimately lead to odd misbehavior and
std::abort during stack unwinding when using _Unwind_RaiseException from
libgcc.a instead of from libunwind). (There is no libunwind.* in
android-ndk-r16b for 32-bit x86 at least, so is presumably using _Unwind_*
functions from libgcc.a. It doesn't appear to make a difference if it
indirectly uses those _Unwind_* functions from NSSLIB's nspr4, or directly
from libgcc.a included in liblo-native-code.so if the
$(if $(filter armeabi-v7a,$(ANDROID_APP_ABI)),-lunwind)
had a ",-lgcc" else branch.)
* Preceding <https://gerrit.libreoffice.org/#/c/64965/> "Export RTTI symbols
from liblo-native-code.so, for binary UNO bridge" makes sure that excpetions
thrown from the binary UNO bridge can be caught by compiled catch clauses.
Not sure why the corresponding state of
bridges/source/cpp_uno/gcc3_linux_intel shouldn't have run into the same
issue.
* Preceding <https://gerrit.libreoffice.org/#/c/64966/> "Adapt gcc3_linux_arm
__cxa_exception to NDK 18 libc++abi" makes sure that our version of
__cxa_exception matches the version from libc++abi. This is clearly not
relevant for 32-bit x86. (The comment there android-ndk-r18b, but the
additional member is already present in
android-ndk-r16b/sources/cxx-stl/llvm-libc++abi/src/cxa_exception.hpp, too.)
The remainder of this change just drops old armeabi-v7a--specific workarounds
that are no longer needed/no longer work.
Change-Id: Ief4c2d562c5032abe6c3b94ca3b3394be6fcd4d3
Reviewed-on: https://gerrit.libreoffice.org/64973
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It was caused by an unsigned integer underflow i.e. 0 - 1 on size_t.
Change-Id: I579aefa8ffc9e320fadf7180f51711e535fdb778
Reviewed-on: https://gerrit.libreoffice.org/63057
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
This gets rid of the horrible hack in gbuild.mk to accomodate the
case-incorrect iOS platform makefiles that cannot be renamed without
upsetting git on file systems that sadly lack the case sensitivity
feature.
Keep the macro defined to IOS though.
Change-Id: I1022bfef4900da00e75fc1ccce786b20f8673234
Reviewed-on: https://gerrit.libreoffice.org/62705
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I006a16cfc83e5b03408a2e772e752bb210901686
Reviewed-on: https://gerrit.libreoffice.org/61380
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iea609a8e90d8b2bf8bcac2b537699b08073f25ae
Reviewed-on: https://gerrit.libreoffice.org/61379
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...on macOS with case-insensitive file systems. When compiling e.g.
workdir/UnpackedTarball/liborcus/src/parser/base64.cpp, libtool adds -I../..
(presumably to find files like workdir/UnpackedTarball/liborcus/config.h), and
including e.g. <vector> internally includes <version> now, and
workdir/UnpackedTarball/liborcus/VERSION (generated from VERSION.in) happens to
win. So disable generation of VERSION from VERSION.in (Kohei confirmed in
private communication that that file isn't actually used for anything, so not
generating it is fine). (An alternative approach might have been to use
-iquote../.. instead of -I../.., but that's probably hard to shoehorn into the
libtool-generated compiler invocation.)
Change-Id: Id9a6778368796dc2494df3499b5e1ca560df1e56
Reviewed-on: https://gerrit.libreoffice.org/61358
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Tested-by: Jenkins
|
|
Change-Id: I345d2655c1999ab319b92c6e8719c0eb9572000b
Reviewed-on: https://gerrit.libreoffice.org/60731
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
|
|
And make all necessary adjustments for the new version of orcus.
Change-Id: I0dc207162a3ddfaad6da198a3d13b65f530757d5
Reviewed-on: https://gerrit.libreoffice.org/59884
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
|
|
Change-Id: I520b19e2486bf1622206c74649f7105148b7bd87
Reviewed-on: https://gerrit.libreoffice.org/58047
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I70075f4240c75f0f46260bb77b160f0b75d6ae94
Reviewed-on: https://gerrit.libreoffice.org/56354
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
This will be the new baseline for master, since, though this change
is a fully API-compatible, one bug fix wrt the alpha value handling
unfortunately would break some unit tests when using an earlier
version.
Change-Id: I5a17ce4085d3311a165748154d107d12b95e2c71
Reviewed-on: https://gerrit.libreoffice.org/49784
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Tested-by: Kohei Yoshida <libreoffice@kohei.us>
|