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>
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
The libgltf configure.ac script changes the autotools user variables
CFLAGS and CXXFLAGS, which is not allowed and can overwrite user
settings (which it does for the -D_GLIBCXX_DEBUG flag).
So this moves the special compile settings to seperate variables and
passes them to AM_CXXFLAGS and AM_CPPFLAGS, so the library actually
gets compiled with libstdc++ debug objects.
Change-Id: I00989f5fb629a6aac43ee5a2eb287b0491a3b86d
liborcus was not building for me with -flto in CFLAGS, I would have to
fix ar somehow.
-flto in LDFLAGS is just to fix the build if the external library does use
another library built by us with -flto: does happen for liborcus and python3.
It's not like we would use -flto for external libraries consistently anyway,
the only exception is icu: no idea why we build with -flto there.
Change-Id: Ia54d619674b8999ce5e4b920ba77b1587c9cf48d
Christian Lohmaier