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>
In orcus, a solid fill type uses the foreground color only and ignores
the background color. Also, let's not use the alpha component as it
would cause the color to not get rendered at all.
Some patches are applied against liborcus in order to adjust the ODF
styles import code for this change. These changes will be incorporated
in 0.13.3.
Change-Id: I9e8c243cc6a7f366de2393e7b7ecf77366f5f9ea
Reviewed-on: https://gerrit.libreoffice.org/49071
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Tested-by: Kohei Yoshida <libreoffice@kohei.us>
gnustl (and others) are to be removed in future versions of the ndk
also bump gradle and build-tools to current versions along with it
arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix
that later
Change-Id: Ic794c3293b599b77ec48096bf3283a99c09cbb79
Reviewed-on: https://gerrit.libreoffice.org/45163
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Similar to libc++ in C++17 mode, some types like std::auto_ptr are indeed
removed in C++17 mode by default, and need _HAS_AUTO_PTR_ETC=1 to be enabled
(see <https://blogs.msdn.microsoft.com/vcblog/2017/12/08/c17-feature-removals-
and-deprecations/>).
Unlike libc++, also std::binary_function and std::unary_function are removed
(and need the same _HAS_AUTO_PTR_ETC=1 to enable). So either set that flag to
make external code build, or use patches (for external/mdds) to make externals'
files included in LO proper still work there.
Change-Id: I886cc0de8196255334ee03ec48cb4bc54d460afd
Reviewed-on: https://gerrit.libreoffice.org/46514
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...like CreateMutexA redeclared in
workdir/UnpackedTarball/boost\boost/thread/win32/thread_primitives.hpp. As such
problematic Boost include files are apparently not included from LO-proper
source files, only from external, it looks easiest to just silence that with
BOOST_USE_WINDOWS_H here.
Change-Id: Ia5ec2325934e6d7fdcf91e6faa2e671aee2091ae
9a6cdce37e was trying to fix the problem
with exposing deprecated vars and functions in system's error_code.hpp
include file by patching bundled boost version. This approach would
only make sense, when upstream version is going to be fixed ASAP. Apply
another approach, and follow the same pattern as applied in external
libraries, by defining
-DBOOST_ERROR_CODE_HEADER_ONLY \
-DBOOST_SYSTEM_NO_DEPRECATED
instead of patching bundled boost version. This way, the code would
work with unpatched system boost 1.59 final as well.
Change-Id: I8684ca458ea4a5b7d7c3c3acfe7c14a6d19bc665
Reviewed-on: https://gerrit.libreoffice.org/18201
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
This has become necessary after edb38d702d "update
to liborcus 0.9.1; Includes switching to dynamic libs."
For one, pass -Wl,-rpath,$ORIGIN in via LDFLAGS, as is done for various external
projects.
For another, libtool (as internally used by liborcus) unhelpfully adds further
-Wl,-rpath arguments of its own, to make the resulting lib in its presumed
location find its dependent libs in their presumed locations. But we override
all that to the single instdir/program/ directory and corresponding RPATH
$ORIGIN anyway, so the simplest fix to get a clean RPATH appears to outsmart
libtool's attempt add adding further -Wl,-rpath arguments by setting
hardcode_libdir_flag_spec_CXX to empty (see the internals of libtool for why
that works). Other external projects (like redland) suffer from this problem
too and currently have a "dirty" RPATH; fix pending. Until libreoffice-4-1 that
was generally not an issue, presumably because having all libs in solver
happened to cause libtool not to emit any additional -Wl,-rpath arguments.
Change-Id: I80dff5141a33c198f30aecb7c51b41bc06145f1c
Following up on 7a4cc19791 "Also on Linux do not
export symbols from static orcus libraries" that turned out to not be enough to
prevent ASan ODR violation reports after
f0aa1a78fb "For Clang -fsanitize=vptr use
-fvisibility-ms-compat, not -fvisibility=hidden." Given that liborcus is only
ever linked in as a static archive, it is hopefully OK (intended, even?) to not
export any of its symbols.
Change-Id: Ib8eb084def1725374747a389065bf8186218786e
Kohei Yoshida