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>

- configure with:
- --host=wasm64-local-emscripten
- had to make a few externals optional, so adding:
  - --disable-nss
  - --disable-cmis
  - --disable-curl

Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>

The Windows platform is called Arm64. But now that the ID for Mac
is also going to be renamed from arm64 to aarch64, this get's rid
of the arm64 as the UNO identifier and user in gbuild, just like
on all other Arm64 platforms.

Change-Id: I60a7eafd04b426f17b6e41ad9a09e6405c0d4173
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112973
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

It failed for me on Windows with

> config.status: error: in `/cygdrive/c/lo/core/workdir/UnpackedTarball/libffi/x86_64-pc-cygwin':
> config.status: error: Something went wrong bootstrapping makefile fragments
>     for automatic dependency tracking.  Try re-running configure with the
>     '--disable-dependency-tracking' option to at least be able to build
>     the package (albeit without support for automatic dependency tracking).
> See `config.log' for more details
> make[1]: *** [C:/lo/core/external/libffi/ExternalProject_libffi.mk:28: C:/lo/core/workdir/ExternalProject/libffi/build] Error 1

because it didn't find any `make` (I only have an /opt/lo/bin/make installed).

Change-Id: Id3e119bbe37df446571a6ef293b8fae8e5b36fde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99034
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

The build setup is rather horrible, with some minimal gcc MSVC
wrapper. But the DLL is a prerequisite for the Python 3.8 build,
which dropped the internal libffi.

It's also possible to build it statically, but then you have to
patch the Python 3 _ctypes msbuild properties.

This also defaults to explicit --build and --host settings, even
without a cross build, because the predicted name would otherwise
differ (*-unknown-* instead of *-pc-*).

Additionally a "make install" also fails...

Change-Id: Ifb7dac840e23efffb9a5e342560aef9e11e0db79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98436
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>

CPython commit f40d4ddff3c800b3c956a5e8820aabe3aa87cddd "Closes #27979:
Remove bundled copy of libffi" causes a bit of a problem because it
turns out that libffi isn't all that stable; there's libffi.so.5 on
CentOS 6, libffi.so.6 on CentOS 7 and libffi.so.7 on
lo_daily_update_gandalf tinderbox.

So we have to bundle it in LO; it's only used on GNU/Linux currently.

CPython commit 32119e10b792ad7ee4e5f951a2d89ddbaf111cc5 "bpo-35947:
Update Windows to the current version of libffi (GH-11797)" also removes
the libffi for MSVC, so in a future python upgrade we will have to build
libffi for MSVC too.

The libffi fork for MacOSX is still in CPython git master.

(regression from b10be5d48433076f0b7238d818020f708553e114)

Change-Id: Ibc20cf8cd3614cf9941b6970662bd930496776b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86493
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>