In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
I assume this is a compiler bug, the patch can be dropped when we don't
build on this baseline anymore.
Change-Id: Ic65f830b888864db075efefd5b2e5d2520d9213e
Reviewed-on: https://gerrit.libreoffice.org/34033
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Initial use case is to avoid creating a whole Draw document + a poppler
process for each and every PDF image we load in a document.
The MSVC patch is only to support MSVC 2013, as upstream already moved
to MSVC 2015.
Change-Id: I3c9dbac3e3de9f2e874ca4cfec0a9dd8a388b87c
Reviewed-on: https://gerrit.libreoffice.org/34022
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
It's faster to change our code not to rely on -DSOLARIS than to
wait for python developers to remove such nonsense from their public
headers.
Change-Id: I3ab05d41bbb51b91a2add599339ce334b5099330
in particular, libgpg-error and libassuan
This only downloads and unpacks the tarball. Building them needs
some work still
Change-Id: I562fd01571929ddfb47a319038f88ea8dbfb4bdd
Reviewed-on: https://gerrit.libreoffice.org/33712
Reviewed-by: Siegmund Gorr <siegmund.gorr@cib.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
LibreOffice has had direct support for Google Drive since (I think) 5.1,
via libcmis.
Change-Id: I7587923b3fd7dd505124b790066cdaa99a858af1
Reviewed-on: https://gerrit.libreoffice.org/33822
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
When libtool links a library with another libtool-based library, it
replaces -lfoo by path to installed foo, like $foo-libdir/libfoo.la.
harfbuzz would be installed to /usr/local/lib by default, therefore
libtool replaces -lharfbuzz by /usr/local/lib/libharfbuzz.la in
libfreetype.la, which causes a failure (nonexistent file) when building
fontconfig...
Change-Id: Ie2510034e69803af084dd90671fdbc8f6863fcf2
The Yocto-based GNOME 3.20 SDK used to build the LO Flatpak has a broken
xml2-config. I cannot understand why the previous workaround worked fine with
raptor2-2.0.9 in LO 5.2 and fails with raptor2-2.0.15 since LO 5.3, but this
updated workaround keeps raptor's configure happy.
Change-Id: Ibfb2cb8a718f744e1bb4045082520fb186d6062b
...to avoid UBSan (on Linux) reporting a ODR violation between
google_breakpad::MinidumpDescriptor::kMicrodumpOnConsole (workdir/
UnpackedTarball/breakpad/src/client/linux/handler/minidump_descriptor.cc)
defined in both the crashreport and sofficeapp dynamic libs.
Change-Id: I686a6e2041c70f0aa17a774d705dc71d95d20183
- fixes some four CVEs
- and a ton of other fixes & improvements
Change-Id: I2312f30f72c914c7e930c59ddbe44fb8a282c0a5
Reviewed-on: https://gerrit.libreoffice.org/33471
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
This reverts commit 128e7ce3ffa50b11b2d5ff9777a27b095a84e5d7 (plus
40b44f7eb25114e5e4e19e571b8781580a938ca6 "Remove line again that was committed
in error" follow-up), now that the cause is found and addressed with
592f4f6a5941e42e6b2b3fa76e74b8ad509724c9 "external/firebird: Backport fix for
CORE-5452 causing spurious SEGV".
Change-Id: I84ddc90707693c2577ad0cd913e987bc9e173e34
Reviewed-on: https://gerrit.libreoffice.org/33229
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
- fixes some minor CVEs
- drop python-vc2013.patch.1
- drop python-3.3.3-py17797.patch.1:
the bug was fixed in MSVC2015 runtime so not relevant
- drop python-lsan.patch.0:
fixed upstream
- ubsan.patch.0:
drop hunks that were fixed upstream
- python-3.5.0-tcltk.disable.patch:
merge into msvc-disable.patch.1
Change-Id: I2aecae446539d28eaf3eb64ee67581596019335d
Reviewed-on: https://gerrit.libreoffice.org/33225
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
The original patch caused compilation of x86-ffi64.c to fail, but that
failure was silently ignored by the build.
Change-Id: I93a0cde041b8f9546873d6cc30c1b690da098642
Check for a macro that is defined by the compiler, we don't really need
one defined by the build system.
Change-Id: Iccb8e3198396881395c97a6b81690ebe64b7e9d2
...while building LO. Patches from <https://github.com/FirebirdSQL/firebird>'s
B3_0_Release branch; to apply, 0002 needed 0001 first (which looks like a
reasonable thing to include in itself, anyway), plus a trivial whitespace
modification, plus an additional #include for Windows.
Change-Id: Idd2e326432fa52762742a168c7e880a9c6fb650c
Reviewed-on: https://gerrit.libreoffice.org/33186
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
