In other external projects using libtool, we fix that by patching configure,
resetting hardcode_libdir_flag_spec[_CXX] at the end of the linux*) case block
that sets the Linux-specific value. But here we run autoreconf in
ExternalProject_libassuan, so that patch in configure would be overwritten. The
relevant code in configure comes from autoconf boilerplate, so we cannot just do
the same patch in configure.ac. But we can reset hardcode_libdir_flag_spec
sufficiently late in configure.ac so that things still work as intended.
Disable tests that would build executabes linking against libgpgme.so, which in
turn links against the libassuan and libgpg-error libs, which would no longer be
found by the linker because of the dropped -rpath flags. (Alternatives might
be to pass in LD_LIBRARY_PATH or to link with --allow-shlib-undefined.)
Change-Id: I7e37abf802d213347bd80383b7980d85cf0762d4
Reviewed-on: https://gerrit.libreoffice.org/50960
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In other external projects using libtool, we fix that by patching configure,
resetting hardcode_libdir_flag_spec[_CXX] at the end of the linux*) case block
that sets the Linux-specific value. But here we run autoreconf in
ExternalProject_libassuan, so that patch in configure would be overwritten. The
relevant code in configure comes from autoconf boilerplate, so we cannot just do
the same patch in configure.ac. But we can reset hardcode_libdir_flag_spec
sufficiently late in configure.ac so that things still work as intended.
Change-Id: Ic6c6123bcfe8bc2dac87812f919842519374abaa
Reviewed-on: https://gerrit.libreoffice.org/50959
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which only patched configure.ac not configure, and the latter does not appear
to be regenerated from the former in ExternalProject_libgpg-error
Change-Id: Id0132ed8fd8ea3a5012e4a2bc309bd5f3983ad11
Reviewed-on: https://gerrit.libreoffice.org/50954
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
pdfium now has a build_config.h which is something between a generated
file (it's not part of git) and a normal header (works in a way, so the
same header works for all platforms), handle it the same way as clucene.
Change-Id: I674eca0c52fb8681c3a20501e39f95a8f9d8724e
Reviewed-on: https://gerrit.libreoffice.org/50840
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
except on windows, where gla11y will resort to python's internal xml parser,
which does not provide line numbers.
This allows gla11y to be runnable on all systems.
Change-Id: Ica4eb90f59bddfcefd783fc2ed9c8c27357e7572
Reviewed-on: https://gerrit.libreoffice.org/50115
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...by CppunitTest setting LD_LIBRARY_PATH to include instdir/program.
This causes the spawned gpg-agent to load instdir/program/libassuan.so.0
instead of /usr/... and fail with:
writev(2, [{iov_base="gpg-agent", iov_len=9}, {iov_base=": ",
iov_len=2}, {iov_base="relocation error", iov_len=16}, {iov_base=": ",
iov_len=2}, {iov_base="gpg-agent", iov_len=9}, {iov_base=": ",
iov_len=2}, {iov_base="symbol assuan_sock_set_system_ho"...,
iov_len=118}, {iov_base="", iov_len=0}, {iov_base="", iov_len=0},
{iov_base="\n", iov_len=1}], 10) = 159
The failure happens in the libreoffice-6-0 branch on Fedora 27, whereas
the master branch doesn't fail because it has a newer version of
libassuan that happens to provide the required symbol.
Fix this by applying the patch that was added for ASAN in
d15f042abd to clear LD_LIBRARY_PATH
always on Linux.
Change-Id: I6a5c7fdfdd32234f39a182581b03d79739880c11
Reviewed-on: https://gerrit.libreoffice.org/50056
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.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>
This patch allows us to use our own bundled TWAINDSM.dll (from
twain-dsm project, http://www.twain.org, https://github.com/twain/twain-dsm)
on 64-bit Windows systems that don't have their own TWAIN DLL,
and without requiring users to install it from some other source.
The DLL is put into INSTALLOCATION/program along soffice.bin.
Of course, TWAIN sources still need to be 64-bit themselves (i.e.,
true 64-bit TWAIN drivers required) to be usable by 64-bit program.
Also this drops external/twain/inc/twain/twain.h, which is an old
version copied from twain-dsm, and instead uses the tarball to get
the header (required by Library_scn on both 32- and 64-bit Windows).
Change-Id: I191027f3221ce46db17f50db91c9cb9315900810
Reviewed-on: https://gerrit.libreoffice.org/46992
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
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>
> [CXX] vcl/unx/gtk3_kde5/gtk3_kde5_folderpicker.cxx
> In file included from vcl/unx/gtk3_kde5/gtk3_kde5_folderpicker.cxx:20:
> In file included from vcl/unx/gtk3_kde5/gtk3_kde5_folderpicker.hxx:30:
> In file included from vcl/unx/gtk3_kde5/gtk3_kde5_filepicker_ipc.hxx:29:
> In file included from workdir/UnpackedTarball/boost/boost/process/child.hpp:22:
> In file included from workdir/UnpackedTarball/boost/boost/process/detail/execute_impl.hpp:24:
> workdir/UnpackedTarball/boost/boost/process/detail/posix/executor.hpp:446:5: error: 'BOOST_POSIX_HAS_VFORK' is not defined, evaluates to 0 [-Werror,-Wundef]
> #if BOOST_POSIX_HAS_VFORK
> ^
under --enable-gtk3-kde5
Change-Id: Ib4648d1337a493c35b35897dc71c5e971c6eb214
Extend vcl::PDFExtOutDevData so that it's possible to use it outside the
PDF export; this way the EPUB export can know which chapters start on
which page.
This means fixed and reflowable layout has the same table of contents,
instead of just Page <N> in the fixed layout case.
Change-Id: I935fb23c66ec747431b91e83b0e677d4e5f704b9
Reviewed-on: https://gerrit.libreoffice.org/48332
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
This claims to support Visual Studio 2017.4, but not the current
2017.5.
* remove boost.auto_link.patch; it does not apply; not sure why we
need this if we can just define BOOST_ALL_NO_LIB
(see commit 7f2e168421)
* remove some hunks from clang-cl.patch.0 that look fixed upstream
* add a global workaround for spurious GCC warning:
oox/source/drawingml/shape.cxx:921:54: error:
‘oShadowColor.boost::optional_detail::tc_optional_base<int>::m_storage’
may be used uninitialized in this function
[-Werror=maybe-uninitialized]
aFormat.Color = *oShadowColor;
Change-Id: I1eb1d8b66554a84a7d7269f1faaa98695fe2f501
Reviewed-on: https://gerrit.libreoffice.org/48187
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
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>
...adding two more wrapper files missing from
aef6da021d "Silence clang-cl -Werror,-Wmicrosoft-
unqualified-friend in external/boost", necessary since
653736fb23 "pdf: use bimap for GraphicsContext-id
map"
Change-Id: Ied377274d355f27af5d97d7bea89e3b598d9b7d0
Reviewed-on: https://gerrit.libreoffice.org/47688
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...messages like:
> workdir/UnpackedTarball/boost\boost/bimap/detail/map_view_iterator.hpp(138,18): error: unqualified friend declaration referring to type outside of the nearest enclosing namespace is a Microsoft extension; add a nested name specifier [-Werror,-Wmicrosoft-unqualified-friend]
> friend class iterator_core_access;
> ^
> ::boost::iterators::
Change-Id: I393b7c95943a55d5f755cfed41e0b7bc3306c568
Reviewed-on: https://gerrit.libreoffice.org/47673
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
For whatever reason OpenSSL wants to use "masm" (ml.exe) on 32-bit
builds but "nasm" on 64-bit builds - this despite INSTALL.W32 claiming
that only nasm is "supported".
But /safeseh doesn't make sense on 64-bit anyway because there
is no "unsafe" SEH there, so just apply the patch only for 32-bit.
Change-Id: Ie32b17dfeeaf11c49ee29c3181021ffa5bd99091
David Tardon