With this new version, the build started to fail with
error: ‘XML_Size XML_GetCurrentColumnNumber(XML_Parser)’ is deprecated: please use XML_GetCurrentColumnNumber64 instead [-Werror=deprecated-declarations]
so we need to check the expat version in case the system expat
is older than 2.9
Also add 0001-fix-XML_GE-is-not-defined-evaluates-to-0-Werror-unde.patch
to fix
error: "XML_GE" is not defined, evaluates to 0 [-Werror=undef]
1087 | # if XML_GE == 1
| ^~~~~~
cc1plus: all warnings being treated as errors
Change-Id: If4f1d652941b7766ed94b65a6eaa018f37c89387
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211867
Tested-by: Jenkins
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Downloaded from https://github.com/libexpat/libexpat/releases/download/R_2_8_2/expat-2.8.2.tar.xz
With this upgrade, building expat started to fail with
error: #error You do not have support for any sources of high quality entropy enabled. For end user security, that is probably not what you want. Your options include: * Linux >=3.17 + glibc >=2.25 (getrandom): HAVE_GETRANDOM, * Linux >=3.17 + glibc (including <2.25) (syscall SYS_getrandom): HAVE_SYSCALL_GETRANDOM, * BSD / macOS >=10.7 / glibc >=2.36 (arc4random_buf): HAVE_ARC4RANDOM_BUF, * BSD / macOS (including <10.7) / glibc >=2.36 (arc4random): HAVE_ARC4RANDOM, * BSD / macOS >=10.12 / glibc >=2.25 (getentropy): HAVE_GETENTROPY, * Linux (including <3.17) / BSD / macOS (including <10.7) / Solaris >=8 (/dev/urandom): XML_DEV_URANDOM, * Windows >=Vista (rand_s): _WIN32. If you insist on not using any of these, bypass this error by defining XML_POOR_ENTROPY and be vulnerable to hash flooding; you have been warned. If you have reasons to patch this detection code away or need changes to the build system, please open a bug. Thank you!
154 | # error You do not have support for any sources of high quality entropy \
so use the different entropies available in each OS
Change-Id: I95cc761c17b61f8d1684d3af482a3e296025e22c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207318
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
it fails with
/home/tdf/lode/jenkins/workspace/lo_gerrit/tb/build_master/workdir/UnpackedTarball/expat/lib/random_getrandom.c:78:14: error: call to undeclared function 'syscall'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
78 | (int)syscall(SYS_getrandom, currentTarget, bytesToWrite,
| ^
/home/tdf/lode/jenkins/workspace/lo_gerrit/tb/build_master/workdir/UnpackedTarball/expat/lib/random_getrandom.c:78:22: error: use of undeclared identifier 'SYS_getrandom'
78 | (int)syscall(SYS_getrandom, currentTarget, bytesToWrite,
| ^~~~~~~~~~~~~
2 errors generated.
Change-Id: I994f10533315c055e1da07fad982a6100e1856ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204732
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
those were from a time where there was 64bit Windows, but no 64bit
builds of LibreOffice/OpenOffice.org - now the only usecase for 32bit
LibreOffice is to use it on 32bit-only machines…
Change-Id: Icf1eacafd9e157788e8ec5a035716327492f5c2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185565
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
No idea why we just provided the platform flags when cross-
compiling. In the curious case, where the host platform is
detected as x86_64-pc-mingw32 per default and we actually
want to override it with x86_64-pc-cygwin, we don't do a
cross compile, but must override the host platform.
But there is additional special handling needed for the omitted
cross-platform build in the special case of --host=i686-pc-cygwin
and --build=x86_64-pc-cygwin, where we deliberatly ignore cross
building; Windows is already a slow build, so try to keep this
optimization (AMD64 can execute x86 binaries).
There is the theoretical case, where the externals config.guess
would have detected something else and that "magically" even
worked, while the LO detected triplet would fail, but this
should be fixed in the external in any way.
Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
See instructions in solenv/gbuild/Trace.mk . This generates a file than
can be viewed e.g. in the Chromium tracing view.
Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
...(new with Clang 10 trunk), where adding even an offset of 0 to a null pointer
is UB in C. Seen when building CustomTarget_writerfilter/source:
> [PY ] CustomTarget/writerfilter/source/ooxml/resourceids.hxx
> workdir/UnpackedTarball/expat/lib/xmlparse.c:6488:23: runtime error: applying zero offset to null pointer
> #0 in hashTableIterInit at workdir/UnpackedTarball/expat/lib/xmlparse.c:6488:23
> #1 in dtdDestroy at workdir/UnpackedTarball/expat/lib/xmlparse.c:6130:3
> #2 in XML_ParserFree at workdir/UnpackedTarball/expat/lib/xmlparse.c:1368:5
> #3 in xmlparse_dealloc at workdir/UnpackedTarball/python3/Modules/pyexpat.c:1222:9
> #4 in insertdict at workdir/UnpackedTarball/python3/Objects/dictobject.c:807:9
> #5 in _PyObjectDict_SetItem at workdir/UnpackedTarball/python3/Objects/dictobject.c:3927:19
> #6 in _PyObject_GenericSetAttrWithDict at workdir/UnpackedTarball/python3/Objects/object.c:1159:19
> #7 in PyObject_SetAttr at workdir/UnpackedTarball/python3/Objects/object.c:930:15
> #8 in PyEval_EvalFrameEx at workdir/UnpackedTarball/python3/Python/ceval.c:2310:19
[...]
Change-Id: I152ddb20c726dbeb638c5fab4403423f5c6da7b5
Reviewed-on: https://gerrit.libreoffice.org/81284
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
As in, really disable, so that they do not even show. This moreover
avoids tons of D9025 warnings from MSVC about overriding -W4 with -w.
Change-Id: Ia2e72fd72d883d91bdd89e467ee42f259e2ae033
Reviewed-on: https://gerrit.libreoffice.org/72899
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This reverts commit 346121398b.
upstream fix is to fix configure to do a link check instead of
compile-only for getrandom.
See f78ed1ec52
Change-Id: Ia9a3f1c2091048778e2bf4773f9e31ae4700ce0c
xmlparse.c has a
#define buffer something
later
#include something
that happens to use buffer as a parameter.
Change-Id: I7378aa9481b30364097c70317c794c0bcca2f05c
Reviewed-on: https://gerrit.libreoffice.org/39109
Reviewed-by: jan iversen <jani@libreoffice.org>
Tested-by: jan iversen <jani@libreoffice.org>
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>
Compilation of the link target's source files does not require the
external project to be built, just unpacked, unless the project
generates some needed headers during configure/build.
Change-Id: I2c9947cf13ce86878d2649829052551fc54f3883
Xisco Fauli