* 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>
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>
...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>
...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>
Otherwise those external projects will fail, because with only VS2013 installed
there is no ToolsVersion 4.0 (which is set inside the VC projects files).
http://msdn.microsoft.com/en-us/library/bb383985.aspx
Change-Id: I144ba1ef95372226ebadb082e3a78155cca316fd
To build a universal binary in Mac OS X 10.6+ with an Intel processor, it is better to set --with-universal-archs=intel, remember that Rosetta is not installed by default in Mac OS X v10.6 and it is neither included nor supported in Mac OS X v10.7 or later.
If we don't use --with-universal-archs then the configure.ac sets the architectures:
...
UNIVERSAL_ARCHS="32-bit"
if test "`uname -s`" = "Darwin"
then
if test -n "${UNIVERSALSDK}"
then
if test -z "`/usr/bin/file "${UNIVERSALSDK}/usr/lib/libSystem.dylib" | grep ppc`"
then
UNIVERSAL_ARCHS="intel"
fi
fi
fi
...
In Snow Leopard (Mac OS 10.6):
/usr/bin/file /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib: Mach-O universal binary with 4 architectures
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture ppc7400): Mach-O dynamically linked shared library stub ppc
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library stub ppc64
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture i386): Mach-O dynamically linked shared library stub i386
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library stub x86_64
/usr/bin/file /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib: Mach-O universal binary with 3 architectures
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library stub x86_64
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib (for architecture i386): Mach-O dynamically linked shared library stub i386
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib (for architecture ppc7400): Mach-O dynamically linked shared library stub ppc
If x86_64 (for OS X 10.8+) or PPC (for OS X 10.5) is only desired then a universal binary is not useful and we don't have to use --enable-universalsdk=${UNIVERSALSDK}.
Change-Id: Ib0578cfdb912fed5a803df3d2e04d2b037cfe13f
Reviewed-on: https://gerrit.libreoffice.org/10249
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
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>
VS2012 did change return value of fileno function, this results in a
crash when run in GUI mode (but not when launching from a shell), as
python tries to access the nonexisting stdin/stdout/stderr
Also explicitly target Windows XP
Change-Id: Ic783713b55453f3c38b2e766a664b7f4678711de
liborcus was not building for me with -flto in CFLAGS, I would have to
fix ar somehow.
-flto in LDFLAGS is just to fix the build if the external library does use
another library built by us with -flto: does happen for liborcus and python3.
It's not like we would use -flto for external libraries consistently anyway,
the only exception is icu: no idea why we build with -flto there.
Change-Id: Ia54d619674b8999ce5e4b920ba77b1587c9cf48d
The assumption that all configure variables had been normalized to
TRUE/<empty> turned out not to hold; convert a bit more in that
direction.
(regression from 4af38b099c)
Change-Id: I2127c515e8a833a07c9b26ed9d693ce5a1853fe4
Michael Stahl