summaryrefslogtreecommitdiff
path: root/solenv
AgeCommit message (Collapse)Author
2019-01-29Rename ScFilterDescriptorBaseObj to ScFilterDescriptorBaseJens Carl
Rename ScFilterDescriptorBaseObj to ScFilterDescriptorBase so it matches the object name we test against. Change-Id: Ia5ce59997e99b2b537e50ddfeaa9d96b2b55555f Reviewed-on: https://gerrit.libreoffice.org/67033 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
2019-01-28Upgrade libatomic_ops to latest libatomic_ops-7.6.8.tar.gzStephan Bergmann
...from <https://github.com/ivmai/libatomic_ops/wiki/Download>. (The md5sum given there is 99128f05e3e3f4e0cd39aa23f23bbe0c.) The old version of external/libatomic_ops failed to build at least when building a Flatpak for aarch64, see <https://flathub.org/builds/#/builders/39/builds/702/steps/5/logs/stdio>: [...] > Making all in src > Making all in atomic_ops > Making all in sysdeps > In file included from atomic_ops_stack.h:32, > from atomic_ops_malloc.c:20: > atomic_ops.h:343:4: error: #error Cannot implement AO_compare_and_swap_full on this architecture. > # error Cannot implement AO_compare_and_swap_full on this architecture. > ^~~~~ > atomic_ops.c:97:1: error: unknown type name ‘AO_TS_t’; did you mean ‘AO_TS_T’? > AO_TS_t AO_locks[AO_HASH_SIZE] = { > ^~~~~~~ > AO_TS_T [...] (cf. <https://github.com/flathub/org.libreoffice.LibreOffice/pull/67/commits/ 48b22dbabc06f1822df74f755096cf0ea5ba2499> "Upgrade libatomic_ops to latest libatomic_ops-7.6.8.tar.gz") Change-Id: Icc040cc47f45f71577995a2ff9c63df97150bdea Reviewed-on: https://gerrit.libreoffice.org/66983 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-28aarch64 and arm need libatomic_opsStephan Bergmann
(cf. LO's configure.ac, needed for external/firebird on non-x86[-64]), but org.freedesktop.Sdk//18.08 apparently doesn't provide it (while org.freedesktop.Sdk//1.6 apparently did) (cf. <https://github.com/flathub/org.libreoffice.LibreOffice/pull/67/commits/ b2762523a4678bedd55c11db232868cbaf9c7bdd> "aarch64 and arm need libatomic_ops") Change-Id: I6eb060251ce85bfd399b72d9c90a93497a3a9029 Reviewed-on: https://gerrit.libreoffice.org/66987 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-28org.freedesktop.Sdk//18.08 `uname -i` always returns "unknown"Stephan Bergmann
(cf. <https://github.com/flathub/org.libreoffice.LibreOffice/pull/67/commits/ deda15380b436ca8fe62e2ebc1feec8bcb6dd43e> "org.freedesktop.Sdk//18.08 `uname -i` always returns 'unknown'") Change-Id: Id158d769edb07aa09189907d120cb1e9cd8d9b17 Reviewed-on: https://gerrit.libreoffice.org/66985 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-26tdf#45904 Move XEnumerationAccess Java test to C++Jens Carl
Move XEnumerationAccess Java test to C++ for ScNamedRangesObj. Change-Id: Ia19281b8e481eda2535eb6f26c60dedc65f1beec Reviewed-on: https://gerrit.libreoffice.org/66933 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
2019-01-25oox: turn on clang-format for WpsContextMiklos Vajna
This had manual consistent formatting. Recently it was broken, so bring back consisency by using clang-format. Change-Id: I742f9a4f328a7455f2e2c7dde4e3cb2624eb9178 Reviewed-on: https://gerrit.libreoffice.org/66885 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-01-25tdf#45904 Move XPropertySet Java tests to C++Jens Carl
Move XPropertySet Java tests to C++ for ScTableValidationObj. Change-Id: If058f40ff73203d2705bf9841d0496d52ff93ed8 Reviewed-on: https://gerrit.libreoffice.org/66890 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
2019-01-24postprocess: Some .svg images were missing previously.Jan Holesovsky
Change-Id: I6c42b1f94f6510e42049bc7c7fc040f17e6edae6 Reviewed-on: https://gerrit.libreoffice.org/66773 Tested-by: Jenkins Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2019-01-24Drop unnecessary gb_DEBUG_CFLAGSStephan Bergmann
...which was at maximum set to GCC's -finline-limit=0 -fno-inline (solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug builds "since forever", but that looks very much like cargo cult: -fno-inline "is the default when not optimizing" anyway (<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline (and maybe was present for ancient compilers that only supported -finline-limit but not -fno-inline?). Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874 Reviewed-on: https://gerrit.libreoffice.org/66836 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-23Drop use of obsolete GCC -fno-default-inlineStephan Bergmann
...that is documented as: "Does nothing. Preserved for backward compatibility." ever since <https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=160384> from 2010. -fno-default-inline was the only value ever set in gb_DEBUG_CXXFLAGS, so the latter can be removed now. The use of gb_DEBUG_CXXFLAGS had accidentally already been removed from gb_LinkTarget__get_debugcxxflags with e751e24250fda31dde52b3c65ca79f86142dc789 "--enable-optimized should be orthogonal to --enable-debug/--enable-dbgutil", and that leaves gb_LinkTarget__get_debugcflags and gb_LinkTarget__get_debugcxxflags with identical definitions, so replace those two with a single gb_LinkTarget__get_debugflags. Some external modules had used only gb_DEBUG_CXXFLAGS, when this was apparently meant to be used in addition to gb_DEBUG_CFLAGS, so those uses have been changed to gb_DEBUG_CFLAGS now. Change-Id: I84ea0ab1233569b0b02ca057240a71f138352381 Reviewed-on: https://gerrit.libreoffice.org/66808 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-21Slience bogus -Werror=maybe-uninitializedStephan Bergmann
...as emitted by at least GCC 8.2 with --enable-optimized, e.g. at: > In file included from include/rtl/ustring.hxx:37, > from include/cppuhelper/factory.hxx:26, > from unoxml/source/rdf/librdf_repository.hxx:24, > from unoxml/source/rdf/librdf_repository.cxx:20: > include/rtl/string.hxx: In static member function ‘static std::shared_ptr<{anonymous}::librdf_TypeConverter::Node> {anonymous}::librdf_TypeConverter::extractNode_NoLock(const com::sun::star::uno::Reference<com::sun::star::rdf::XNode>&)’: > include/rtl/string.hxx:294:27: error: ‘*((void*)(& type)+8).rtl::OString::pData’ may be used uninitialized in this function [-Werror=maybe-uninitialized] > rtl_string_release( pData ); > ~~~~~~~~~~~~~~~~~~^~~~~~~~~ > unoxml/source/rdf/librdf_repository.cxx:2094:30: note: ‘*((void*)(& type)+8).rtl::OString::pData’ was declared here > boost::optional<OString> type; > ^~~~ This appears to be a common pattern of false positives with uses of boost::optional, common enough to disable the warning globally for affected compilers, even if there would also be useful findings by that warning (e.g., <https://gerrit.libreoffice.org/#/c/66619/> "Fix -Werror=maybe-uninitialized"). I didn't bother to file a GCC bug for the reproducer used in configure.ac, <https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=maybe-uninitialized> already shows lots of open bugs in that area, and the documentation at <https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Warning-Options.html> states that "GCC may not be able to determine when the code is correct in spite of appearing to have an error." (Clang appears to not support -Wmaybe-uninitialized at all, so exclude it from the configure.ac check, to not have the check's failure result in an unsupported -Wno-maybe-uninitialized end up on the compiler command line.) Change-Id: Ifb9ca4c342750eae54f7e1a01506101310484c7e Reviewed-on: https://gerrit.libreoffice.org/66621 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-17Adapt solenv/flatpak-manifest.in to recent download.lst changesStephan Bergmann
Change-Id: I9400c8fa5b7763debc13274f7e001b6425d8392e Reviewed-on: https://gerrit.libreoffice.org/66496 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-16Move XStyleLoader2 tests to ScStyleFamiliesObjJens Carl
Change-Id: Ibba0464d17a9517eb48f3f33b46db2455093ac52 Reviewed-on: https://gerrit.libreoffice.org/66413 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
2019-01-16Minimum Supported Version is VS2017himajin100000
Change-Id: Id771f1fe0d8c6702a52836f6229a944d259fed4c Reviewed-on: https://gerrit.libreoffice.org/66424 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-01-16external: update pdfium to 3667Miklos Vajna
Change-Id: Ie4f0cc8f06432e182ce7ffcae5269075d12658ef Reviewed-on: https://gerrit.libreoffice.org/66408 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-01-13array_view was changed to span in upcoming C++20Stephan Bergmann
...see <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0122r7.pdf> "span: bounds-safe views for sequences of objects". o3tl::span is still an incomplete approximation of std::span; removed those o3tl::array_view members that are not present in std::span (and were not used in the code). Relies on C++17 __has_include to use standard <span> where available (e.g., in LLVM 7 libc++). Change-Id: I82a7e246b61b2456fa6183025d25eec4121ad3c9 Reviewed-on: https://gerrit.libreoffice.org/66215 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-11Drop o3tl/string_view.hxxStephan Bergmann
...now that all of its uses have been replaced with C++17 <string_view>. The LO-specific o3tl::basic_string_view ctors with OString and OUString params have meanwhile been replaced with OString and OUString conversion functions (in dac7be50cff94e0c34cdca5ac7e35c19685c40c1 "o3tl::string_view -> std::string_view (in configmgr)"), the ctor with OUStringLiteral turned out to be no longer(?) needed anyway, and the LO-specific o3tl::toOUString has meanwhile been replaced with an OUString ctor with std::u16string_view param (in 6856da30665705be6380e84cf55de954c41f15d1 "o3tl::string_view -> std::string_view (in embedserv)"). Change-Id: Ie5215b07e2387560fb7e94de8b5a963241539c64 Reviewed-on: https://gerrit.libreoffice.org/66144 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-10Related: tdf#44076 do not leave cast to int to undefined behaviourEike Rathke
... if the double is an out-of-int-range value. Also catch domain and pole and range errors. Move this to it's own sc::power() function that can be reused for example by ScMatrix::PowOp() to be congruent. Change-Id: I88331e02e6cdfb5e1dcbf81622d3fc7ce4510478 Reviewed-on: https://gerrit.libreoffice.org/65986 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2019-01-09update uitest debugging instructions to account for gtk3 backend issueNoel Grandin
e.g. when debugging UITest_writer_tests2 it gets stuck when the uitest invokes dialogs Change-Id: I8276a8d7e885be5f47309beeec1f4c3c9d12ee32 Reviewed-on: https://gerrit.libreoffice.org/66002 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-03svm xml dumper: move this from test to vclMiklos Vajna
This is very useful functionality, this way it can be invoked from the debugger and/or nested into an outer xml dump (sw/sd doc model dump) more easily. Change-Id: If6c83b11d0f3e65fcce71e8d820c6bc354f64d68 Reviewed-on: https://gerrit.libreoffice.org/65834 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-01-03Update Flatpak to OpenJDK11Stephan Bergmann
see <https://github.com/flathub/org.libreoffice.LibreOffice/issues/57> "OpenJDK 11 is available". Change-Id: Ie24ed7349ca9a4a57c1a8d18d10b29c4a37e259c Reviewed-on: https://gerrit.libreoffice.org/65830 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-02upload libwpg 0.3.3David Tardon
Change-Id: Iac2c3f75eda07b7381e57dba389c9836ab26502f Reviewed-on: https://gerrit.libreoffice.org/65781 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2018-12-31for tests MOZILLA_CERTIFICATE_FOLDER should be set to empty not 0Tomaž Vajngerl
0 means it has a value (string "0") but we check for an empty string. The end result is the same however. Change-Id: I01fed189eaf37673fdb254884c5e7382914b5211 Reviewed-on: https://gerrit.libreoffice.org/65766 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2018-12-30upload libqxp 0.0.2David Tardon
Change-Id: Idda6c0ce0c087a3be2e7fe31999a7d5a6fde4835 Reviewed-on: https://gerrit.libreoffice.org/65725 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2018-12-29upload libcdr 0.1.5David Tardon
Change-Id: I01454cc35baf96743bd19e64dd3a7269c58621bf Reviewed-on: https://gerrit.libreoffice.org/65715 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2018-12-29upload libwpd 0.10.3David Tardon
Change-Id: I68e3791f50b95956bfe6aae743978994a5f232b4 Reviewed-on: https://gerrit.libreoffice.org/65714 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2018-12-29upload libetonyek 0.1.9David Tardon
Change-Id: Ib29e1a622e25731731512a695443ac2c530d30c2 Reviewed-on: https://gerrit.libreoffice.org/65701 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2018-12-29tdf#114635: reimplement TWAIN-based scan using 32-bit shim on WindowsMike Kaganski
Since TWAIN is only actually available as 32-bit component on Windows, to use it in a 64-bit program, we need a 32-bit shim program that does all actual communication with TWAIN subsystem. This change reimplements TWAIN implementation to be a separate 32-bit process. Image is transfered from the shim to main program using file mapping API. This reverts most of commit 585d9806961342e95f7318fb947bd31e9f86dee0. 64-bit LibreOffice doesn't bundle TWAIN DSM library now. TWAIN DSM source code is still used for TWAIN headers. Change-Id: I46f178ad36acd97a9eff156624b99036fcbb83f8 Reviewed-on: https://gerrit.libreoffice.org/65688 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-28upload libcmis 0.5.2David Tardon
Change-Id: I0a7e888af770a332e2fec057507eecebf83621c4 Reviewed-on: https://gerrit.libreoffice.org/65646 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2018-12-27URL fixed. Was broken & linking to deleted page.Howard Johnson
Change-Id: Iefe842aa8ef3b183b90f896902edd8941fb1b238 Reviewed-on: https://gerrit.libreoffice.org/63967 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-21Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: Ic8b2adeb949bfc72830667b6928147ebd053d2f0 Reviewed-on: https://gerrit.libreoffice.org/65517 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-12-21restore the UI test 'debug with two shells' instructionNoel Grandin
seems to be working for me now (and since I was the one that commented the instruction out, seems I must have had something wrong in my environment) Change-Id: Ie8e180a22d6a3dec61686cb38fd41b00f22fe5c7 Reviewed-on: https://gerrit.libreoffice.org/65492 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-20Enable --help=html for flatpakStephan Bergmann
To not increase the size of the main org.libreoffice.LibreOffice app further, the plan was to realize this as an org.libreoffice.LibreOffice.Help extension. Ideally, this would be a localized extension, so that, by default, only a relevant subset of the extension would be downloaded and installed. (But see below.) There are multiple technical problems, as discussed at <https://github.com/ flathub/org.libreoffice.LibreOffice/issues/35#issuecomment-447295308> "Add integrated LibreOffice Help offline": * LO can't pass a file URL with query part to xdg-open, so uses a temporary wrapper .html file that redirects to the target URL. But for the flatpak case this wrapper can't be in /tmp (which isn't visible from outside the flatpak sandbox), but is instead stored in a new temp dir under $XDG_CACHE_HOME (which is always set for flatpaks and /is/ visible form the outside) that is removed on LO exit. * The file URL stored in the temp file must be rewritten from the internal path (/app/libreoffice/help/...) to the path as seen outside the flatpak sandbox. While the path for the org.libreoffice.LibreOffice /app is stored in /.flatpak-info, the external path for the org.libreoffice.LibreOffice.Help extension is different and not stored there. So use a hack trying to construct that path from what information is available in /.flatpak-info. * But the help content consists of locale-specific and shared files, and those reference each other with relative links. But a localized flatpak extension cannot contain shared files, it can only contain per-language sub-dirs. And if the shared help files were kept out of the extension, as part of the app itself, the relative paths among these files inside the flatpak sandbox would differ from those outside of it, so would be broken when viewing the content in the external browser. A solution would either (a) need to somehow rewrite the content of all the help files being served from LO to the external browser, or (b) replicate the shared help files in all the extension's per- language sub-dirs (and if some localization uses en-US content as a fallback for only part of its translated content, e.g., in the case of media files, would need to also replicate that en-US content), or (c) use a non-localized extension that always contains the content for all localizations. For now, I chose the third approach. This makes the org.libreoffice.LibreOffice.Help extension relatively large (the current /app/libreoffice/help tree has a size of ca. 100MB), so that I decided to not have it downloaded and installed automatically ("no-autodownload": true in solenv/flatpak-manifest.in). (I checked with Flatpak 1.0.6 that if the extension should be changed to a localized one with the same name in the future, updating from an older version would work. If the old extension was not installed, just the relevant localizations of the new version will be downloaded and installed. If the old extension was installed, the full set of localizations of the new version will be downloaded and installed.) (As also mentioned at <https://github.com/flathub/org.libreoffice.LibreOffice/ issues/35#issuecomment-447295308>: "A second, minor, nuisance is that, for security reasons, an `xdg-open file:///...html` call from a flatpak leads to an intermediate popup dialog letting the user chose which application to use to open the URI, while e.g. an `xdg-open http:///...html` is allowed to go directly to the user's preferred browser. So accessing help content from LO flatpak would present that popup dialog first, forcing the user to select a browser to proceed.") Change-Id: I35f5a23947dd551dc1b9bff1dd2abd6710073b5f Reviewed-on: https://gerrit.libreoffice.org/65451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-20weld SwTOXEntryTabPageCaolán McNamara
Change-Id: Ib093fbb78a73b26060613ea72030e92f7d3681a5 Reviewed-on: https://gerrit.libreoffice.org/65325 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-20starmath: create SmFilterDetect instances with an uno constructorMiklos Vajna
Change-Id: I11ffe5153bc9ea263cde63093544584f01a344d2 Reviewed-on: https://gerrit.libreoffice.org/65464 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-12-18Natvis: VS has trouble showing sequence of signed charMike Kaganski
Provide a visualizer specialization for this case Change-Id: I54c293972c7e883b8328958f748dba5f2dbd0636 Reviewed-on: https://gerrit.libreoffice.org/65327 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-18tdf121374 ooxmlexport: export H/F to default sectionJustin Luth
It wouldn't be terrible to duplicate headers/footers unnecessarily, but it is terrible to have them disappear. If the last SectPr has no idea about the section start, it can't know whether it is continuous or started with a page break. In that case, just ensure that the header and footer are explicitly written out. This seems to be a DOCX problem only. I think that doc and rtf both write the section information at the BEGINNING of the section, but DOCX writes it at the END. So, sharing code between these two opposite approaches is difficult. A followup commit can try to make it smarter about knowing the start of the section (because usually pPDNd is zero). Another followup commit can add the missing page breaks. Change-Id: Iff54ed097b4f8692d7d7764089002b00fbde4f51 Reviewed-on: https://gerrit.libreoffice.org/64821 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-12-18Resolves: tdf#121676 - Update Liberation fonts from new sourceheiko tietze
Liberation updated from 2.00.1 to 2.00.4 and Liberation-Narrow from 1.07.4 to 1.07.6 Change-Id: I295f82d5b8230cdf8b3347491dd71c8689636d94 Reviewed-on: https://gerrit.libreoffice.org/65273 Tested-by: Jenkins Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>
2018-12-17kde5: remove older kde/tde plugins, and references to thatThorsten Behrens
KDE4 is out of maintenance upstream since Nov. 2014, and binaries provided by TDF have switched to KDE5 as the official backend. Change-Id: I165465b56d3ba3a18912b203c06ae8fc6111c0c9 Reviewed-on: https://gerrit.libreoffice.org/60014 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-12-13Add more missing constructors from chart2/source/chartcore.componentTor Lillqvist
I think it would be better if native-code.py parsed the .component files it is interested in and just copied the constructor names from them to its output? Or are there many cases where it is a carefully manually selected subset of constructors from some .component file that should be put in the generated native-code.h, not all? But even in that case, if some constructor should not be linked in to a mobile app, that could be handled by adding some specific attribute in the .component file. Change-Id: Ib947279610f6755f112d3571512406c5d0cd620d
2018-12-13We need CartesianCoordinateSystem2d for chartsTor Lillqvist
Change-Id: I3edccbe29129f6d60a4ac4627a0ab646e4e42458
2018-12-13loplugin:unusedfields improve write-only logicNoel Grandin
when dealing with modifications to container classes (e.g. std::vector) Change-Id: Ic30043631007355ee9a3d9e3f9b6488b435182d6 Reviewed-on: https://gerrit.libreoffice.org/65050 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-13Switch Android armeabi-v7a to libc++/libc++abi/libunwind tooStephan Bergmann
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>
2018-12-12weld SwCaptionDialogCaolán McNamara
Change-Id: I5babfbf3489f88c5d6cdeffbd514d86368f04fa9 Reviewed-on: https://gerrit.libreoffice.org/65014 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-12weld SwCaptionOptPageCaolán McNamara
Change-Id: I3373a39d6d8b39717b7aec69544a9d2957db15d8 Reviewed-on: https://gerrit.libreoffice.org/65010 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-11mythes is included in org.freedesktop.Sdk//18.08Stephan Bergmann
Change-Id: I9980f60ebe4cef26348fc26af6b56245260abcca Reviewed-on: https://gerrit.libreoffice.org/64937 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-11tdf#121685: also apply DeclareDPIAware manifest to console applicationsMike Kaganski
There's no reason not to; and now soffice.bin itself is built as a console application. Change-Id: Iba080498b02af04780fdfe1053fb00f584eaae81 Reviewed-on: https://gerrit.libreoffice.org/64915 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-07Revert "In flatpak build, disable problematic test using gpg for now"Stephan Bergmann
This reverts commit 23339ec77e38ebdae86eb05a2a3d9a3f5609df64, which is no longer needed after TODO.
2018-12-07Upgrade flatpak to org.freedesktop.Sdk//18.08Stephan Bergmann
...fixing <https://github.com/flathub/org.libreoffice.LibreOffice/issues/54> "Build against org.freedesktop.Platform 18.08" Change-Id: I70448277ce326075435932c75a837bd7be3d4508
2018-12-07Drop obsolete font sources from flatpak manifestStephan Bergmann
...which are no longer used by the LO build since 0ce173b50fd12342979cf3f8f9b2d92267552060 "tdf#103080 Dont package Open Sans and PT_Serif fonts" Change-Id: I9ece7a85fe0003711eb23f332e617b780e6701cd
generated by cgit (git 2.34.1) at 2025-01-31 16:14:10 +0000