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>
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 b10be5d484)
Change-Id: Ibc20cf8cd3614cf9941b6970662bd930496776b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86493
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Jan-Marek Glogowski