The LO python3 target fails for me on Windows with:
C:\lode\dev\core\workdir\UnpackedTarball\python3\PCBuild\openssl.props(24,5):
error MSB3030: Datei "C:/lode/dev/core/workdir/UnpackedTarball/openssl/out32dll\libcrypto-1_1.dll"
konnte nicht kopiert werden, da die Datei nicht gefunden wurde.
[C:\lode\dev\core\workdir\UnpackedTarball\python3\PCBuild\_ssl.vcxproj]
Same for
"C:/lode/dev/core/workdir/UnpackedTarball/openssl/out32dll\libssl-1_1.pdb"
"C:/lode/dev/core/workdir/UnpackedTarball/openssl/out32dll\libcrypto-1_1.pdb"
"C:/lode/dev/core/workdir/UnpackedTarball/openssl/out32dll\libssl-1_1.dll"
Other files were also renamed in a previous hunk of this patch.
For other people these failures are silently ignored, but they
show up in their python3 build.log. But my msbuild version
15.9.21+g9802d43bc3 from VS2017 fails hard on these errors.
So this just adapt the pdb and dll names to match the previous
renames, which passes the copy calls, so the build continues.
Change-Id: Iffc848c334caec534f6e99f8bf83a42da570bbb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87358
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
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>
Of course the autotetection in setup.py strikes again, the build will
fail if the user doesn't have libuuid-devel installed; we'd need to add
a check to LO's configure.ac for libuuid.
Let's just not ship it, not sure if anybody needs it.
Change-Id: I9079309da7d9c16e666fbab30542365124f97860
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86433
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
* external/python3/python-3.3.3-aix.patch.1:
most of it doesn't apply and AIX port isn't maintained anyway so
remove it for now
* external/python3/ubsan.patch.0:
apparently one of the files was removed
* 0001-3.6-bpo-17239-Disable-external-entities-in-SAX-parse.patch.1:
fixed upstream
* python3-osx-avoid-new-10.13.patch.1:
replace with simply passing ac_cv_func_utimensat=no to configure
* external/python3/python-3.5.4-ssl.patch.1:
project files to build OpenSSL removed upstream
* There have been changes to how python locates OpenSSL; new variables
OPENSSL_INCLUDES etc; it turns out that you have to pass one directory
to --with-openssl, as the variables cannot be passed
* libuuid.so.1 is a new dependency of the _uuid module
* libffi.so.6 is a new dependency of the _ctypes module (the bundled
copy of libffi for non-Darwin platforms was removed)
* python-3.3.0-pythreadstate.patch.1:
the PyThreadState functions have been changed such that
CppunitTest_services asserts when there is a PyThreadAttach on top of
PyThreadDetach on top of PyThreadAttach, i.e., 2 PyThreadState per
thread (PyGILState_Check() fails). Instead of patching in additional
workarounds, change PyThreadAttach so that it re-uses an existing
PyThreadState if one exists for the thread.
Change-Id: I24c19d79b43a30709261fd9db66312b2e3872fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84765
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Fixes CVE-2019-9948 CVE-2019-9740 CVE-2019-10160 CVE-2019-16056
and expat CVE-2019-15903.
python-3.3.5-pyexpat-symbols.patch.1 fails to apply, and it's a
mystery why --with-system-expat is used everywhere but on MacOSX,
where 292af048ac disabled it for no
obvious reason, so try to remove the special case and get rid of the
patch.
Change-Id: I5ba4532eb6e7c2fb90daba95d132dcc7c9013d96
Reviewed-on: https://gerrit.libreoffice.org/83117
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
...which was at maximum set to GCC's -finline-limit=0 -fno-inline
(solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug
builds "since forever", but that looks very much like cargo cult: -fno-inline
"is the default when not optimizing" anyway
(<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it
is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline
(and maybe was present for ancient compilers that only supported -finline-limit
but not -fno-inline?).
Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874
Reviewed-on: https://gerrit.libreoffice.org/66836
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
..."target does not support '.file' without a number", which was introduced into
LLVM with <http://llvm.org/viewvc/llvm-project?view=revision&revision=349976>
"[MC] Enable .file support on COFF and diagnose it on unsupported targets",
stating: "The 'single parameter' .file directive appears to be an ELF-only
featurea [sic] that is intended to insert the main source filename into the
string table table [sic]."
And <https://sourceware.org/binutils/docs-2.31/as/File.html> states about the
default single (file name) argument version: "This statement may go away in
future: it is only recognized to be compatible with old as programs."
As external/python3 builds just fine on macOS with that .file directive removed,
lets just do that for now.
Change-Id: Ib28c29d0cacd151437447ccb2f6cfb8925e3e85a
Reviewed-on: https://gerrit.libreoffice.org/65704
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
No need to distribute that, apparently. We don't ship it on Windows,
either.
Change-Id: I76bf77311caceccd07afb0afa2f097b63f58bf54
Reviewed-on: https://gerrit.libreoffice.org/59034
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
At least Fedora 28 glibc-2.27-8.fc28 no longer provides the nis development
headers and libraries. (It only still contains some binaries for backwards
compatibility, in the libnsl sub-package: "This package provides the legacy
version of libnsl library, for accessing NIS services.")
There is probably no real need to have nis.cpython-*m.so contained in
external/python3/ExternalPackage_python3.mk (it probably just happened to build
fine when that list was originally created, so was included).
Change-Id: Ic6128fd872432005c0ded76640c5b56781ca69a1
Reviewed-on: https://gerrit.libreoffice.org/52535
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...introduced with b862cbdd34 "Support MSVC 15.0",
but $(filter ...,) always expands to the empty string, and this is probably what
was intended.
Change-Id: I5865ea13ba3c3d52402bcba48f4f770f6c2b8862
Reviewed-on: https://gerrit.libreoffice.org/34482
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
New compiler changes quite some stuff:
* Compiler detection done based on different registry key
* .NET SDK detection done based on different registry key
* Msbuild installation directory changed
* Merge modules installation directory changed
* SDK number in registry doesn't match the directory name:
(registry key: 10.0.14393, directory name: 10.0.14393.0)
* Compiler, include and library location directories changed
* Architecture specific directory changed: x64 instead of amd64
* Compiler own include directory must be added with -I option
* To force usage of SDK 10 (8.1 is selected per default) new
switch WindowsTargetPlatformVersion is passed to msbuild, to
avoid patching VC project files with this line:
<WindowsTargetPlatformVersion><SDK>/WindowsTargetPlatformVersion>
Known issues:
* Firebird is broken: http://paste.openstack.org/show/594333
Change-Id: I148d7932aff43bbbd07bd493504df974726234c2
Reviewed-on: https://gerrit.libreoffice.org/31279
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.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>
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
- 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
libpython3.so is the "ABI compatible" wrapper library around
libpython3.5m.so - it is not actually used by anything in LO right now,
but let's ensure it has RPATH $ORIGIN just in case.
This revealed that the AIX patch in python3 accidentally changed the
SONAME of libpython3.5m.so from upstream's libpython3.5m.so.1.0
on ELF platforms, because the SONAME variable was set in the shell
command but read as a make variable in the next line, which is actually
evaluated earlier.
So rename a few files in packages to use the upstream SONAME.
Change-Id: I3611f75eee62b0993b853230521a2fa41ac5cd9c
...whose (static) library is called "zlib" instead of just "z".
(I ran into this when trying to do a 32-bit Linux build in a 64-bit environment,
with only very limited 32-bit support installed in the system.)
Change-Id: I9286975917ddf643a22803561677af035e66fb98
Reviewed-on: https://gerrit.libreoffice.org/28964
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Build on Fedora 24 fails with "Python/thread.o: undefined
reference to symbol 'pthread_key_delete@@GLIBC_2.0'"
Change-Id: If23838722e1cd0220c509d25932ae0539e8da7a1
... to avoid calling C:/Windows/system32/{sort,find}.exe, if those
happen to be first in PATH.
On a Windows 7 system, the other conflicts appear to be harmless,
we don't use "more", "expand", "timeout", "whoami".
Change-Id: Iceefeb7ee6725291b04c0eba465991bb1df96b57
Reviewed-on: https://gerrit.libreoffice.org/21175
Tested-by: Jenkins <ci@libreoffice.org>
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.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>
Jan-Marek Glogowski