With all the prerequisites in place, LO can be updated to the
current Python release. Interestingly I found that Cygwin always
seems to use LC_COLLATE=C, probably because the default collation
rules are missing.
Then there are the changes introduced in "PEP 587 -- Python
Initialization Configuration", which appearingly have modified the
DLL search path behaviour on Windows, so the OpenSLL DLLs aren't
found anymore in the program directory. As a workaround, the
OpenSLL and libffi DLLs are now (also) installed into the Python
lib dir on Windows.
Change-Id: Ib82f7b77213da9c525f8c79a13d128d9eec9ca64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98437
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
- 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>
3.5 release is needed for MSVC 14.0 (aka VS 2015) support. Python 3.5
removed build toolchain support for MSVC 2013. Because we still need
to support it, we duplicate the Python directory in externals and
copy old patches and dispatch to this directory for MSVC 2013. Once
the support for MSVC 2013 is dropped on master, this directory can be
removed again.
Change-Id: Idf7bc351239582f583ecbdb53c923cbdcf968089
Reviewed-on: https://gerrit.libreoffice.org/17352
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
The Python build machinery apparently does not use proper autoconfigury to
expand this Info.plist.in file, so can't use @PYTHONFRAMEWORK@ as for the
Info.plist for the framework itself, but have to hardcode LibreOfficePython.
As such I am not sure that Python's way of including an app bundle
inside a framework's Resources subtree is acceptable in the stricter
code signing and Gatekeeper rules that soon will be in effect. Will
see.
Change-Id: I1ef9e7b748d41ec4b32d80e721d5fba5e7a90d18
It should be the basename of the framework. The Python
configury already provides that as @PYTHONFRAMEWORK@.
Change-Id: I116a34c3bcc8f661abe16b2b5cc1b9268ecd2780
this fixes gcc: error: unrecognized command line option '-arch'
The '-arch' option is part of Apple's extensions to GCC, and it is uncompatible
with "vanilla" GCC from FSF. Also, we're not building "universal binaries".
Change-Id: I44e7c72bbb1dd4be5ac9cdbc4f210aaccea513b4
Reviewed-on: https://gerrit.libreoffice.org/10117
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Michael Stahl