and use the same config.h in all platforms.
Compiling these libraries only takes a few seconds
so no need to exclude Windows here
it should also fix the win arm64 build
This patch reverts
commit e4421ce01d
Author: Xisco Fauli <xiscofauli@libreoffice.org>
Date: Mon Nov 10 22:35:22 2025 +0100
sqlite3: don't create a static library on Windows
and part of
commit 1cb84d60d9
Author: Xisco Fauli <xiscofauli@libreoffice.org>
Date: Thu Oct 30 20:11:23 2025 +0100
external: add lzma
Change-Id: Ia66242d4fef78cf8d99f853db4c9eee2e24c62ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194023
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
there was already parts of that in the makefile that would require
running "make gb_GCOV=YES" - but that alone was not enough, you were
also kinda expected to set LDFLAGS on the commandline (or at least it
had bitrotted to this state) - so just make it into a proper configure
switch.
Building with lto fails at least on baseline with
/opt/rh/gcc-toolset-12/root/usr/libexec/gcc/x86_64-redhat-linux/12/ld: /tmp/ccaE1KD4.ltrans31.ltrans.o:(.data.rel.ro.local+0x3befe0)
: undefined reference to `.L1'
/opt/rh/gcc-toolset-12/root/usr/libexec/gcc/x86_64-redhat-linux/12/ld: /tmp/ccaE1KD4.ltrans31.ltrans.o:(.data.rel.ro.local+0x3befe8)
: undefined reference to `.L1'
/opt/rh/gcc-toolset-12/root/usr/libexec/gcc/x86_64-redhat-linux/12/ld: /tmp/ccaE1KD4.ltrans31.ltrans.o:(.data.rel.ro.local+0x3bf018)
: undefined reference to `.L2'
/opt/rh/gcc-toolset-12/root/usr/libexec/gcc/x86_64-redhat-linux/12/ld: /tmp/ccaE1KD4.ltrans31.ltrans.o:(.data.rel.ro.local+0x3bf020)
: undefined reference to `.L2'
[…many more of those with incrementing references…]
So for now warn if both are used.
Change-Id: I2c3427b48174de77a6894293a5e784df8ee24bd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186821
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
on branches 25-2 and 24-8 the python tkinter dylib is back.
The corresponding python module is ignored already, and the tkinter
cpython dylib already was removed in the past, but apparently at some
point that file wasn't generated anymore and the corresponding line to
delete it was removed in 6e62c9df96
That same commit also changed the filenames to use a * wildcard after
the python version, apparently to account for a "d" suffix in the
--enable-dbgutil case. In the spirit of the old commit to avoid rm -f
and to be explicit and catch potential other issues in future remove
that wildcard again/replace the suffix with a macro that contains the
appropriate suffix already as used in ExternalPackage_python3.mk.
Change-Id: I22b49af7dbf9a0bed5c124d9f137b8a38fee7471
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180705
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Downloaded from https://www.python.org/ftp/python/3.11.11/Python-3.11.11.tar.xz
* Add external/python3/replace-powershell-with-wget.patch.1
to avoid
FindPythonForBuild:
Invoke-WebRequest : The request was aborted: Could not create SSL/TLS secure
channel.
At line:1 char:1
+ Invoke-WebRequest https://aka.ms/nugetclidl -OutFile
'C:\cygwin64\home\tdf\jenki ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:Htt
pWebRequest) [Invoke-WebRequest], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShe
ll.Commands.InvokeWebRequestCommand
'py' is not recognized as an internal or external command,
operable program or batch file.
when downloading nuget.exe from https://aka.ms/nugetclidl
using powershell. By default powershell uses TLS 1.0 and the site security requires TLS 1.2,
so it fails with 'The request was aborted: Could not create SSL/TLS
secure channel.'
Kudos to Caolán for helping with a compiling issue.
See https://lists.freedesktop.org/archives/libreoffice/2024-December/092830.html
Change-Id: If66a88dd8f8c7774c49f8c33e9e40d2d5418e7c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178681
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
/bin/sh: line 1: easy_install-3.10: No such file or directory
Also seen in libreoffice-24-2 branch with python 3.8
/bin/sh: line 1: easy_install-3.8: No such file or directory
Change-Id: Ia4b26c4526c03bec2f06f19ec6ea8539332d43da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170176
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
This commit includes the changes in 5e3510dbb6
and 219bef04b7, as well as the following changes:
* add bzip2 as permissable build target when cross compiling for Windows ARM64.
* add external/bzip2/disable-test.patch.0 for cross-compiling.
* revert the changes to configure.ac in 5e3510dbb6.
* change the argument of gb_UnpackedTarball_fix_end_of_line.
Change-Id: Iad8b1ed48d6c56e1302d9ac11620dc8084e79276
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157101
Tested-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
since we won't accept anything lower than 10.14 on master (and 10.13 on
libreoffice-7-4 branch), we don't need those quirks anymore.
Change-Id: Ibc71a2ce7a0dc60769d03d477991b48fc99d534d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143040
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
...to avoid issues like we now experienced on Jenkins box tb76, where e.g.
<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/108402/> failed with
just an unhelpful
> /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/external/python3/ExternalPackage_python3.mk:46: *** file /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/workdir/UnpackedTarball/python3/LO_lib/_elementtree.cpython-3.8d.so does not exist in the tarball. Stop.
> make[1]: *** Waiting for unfinished jobs....
> Makefile:299: recipe for target 'build' failed
> make: *** [build] Error 2
after ExternalProject_python3 had been built successfully, outputting just
> [build PRJ] python3
even though its workdir/UnpackedTarball/python3/build.log states
> *** WARNING: renaming "_elementtree" since importing it failed: pyexpat version is incompatible
and
> Following modules built successfully but were removed because they could not be imported:
> _elementtree
(but which got hidden by gbuild)
Change-Id: I28904ef41cb823e308bb8e15cbe969872702cb55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130355
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
This allows to define the mapping once, and avoid modification in
multiple places each time a new VS version support is added
Change-Id: I93de4c9d78c3f67a0a2e157007e9d13b6f557937
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123163
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This patch changes the configure.ac, so that LibreOffice compiles
with the latest VS 2022 preview.
The option --with-visual-studio=2022 should be added to the
autogen.input, in order to use VS 2022 preview.
Change-Id: Ia1d9bbeabbbd44ffe82af3624151b69d36c0a45c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122133
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
otherwise, we could get issues like
> error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: /Users/stephan/Software/lo/core/workdir/UnpackedTarball/python3/python-inst/@__________________________________________________OOO/LibreOfficePython.framework/Versions/3.8/lib/python3.8/lib-dynload/_curses_panel.cpython-3.8.so (No such file or directory)
> error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: /Users/stephan/Software/lo/core/workdir/UnpackedTarball/python3/python-inst/@__________________________________________________OOO/LibreOfficePython.framework/Versions/3.8/lib/python3.8/lib-dynload/_curses.cpython-3.8.so (No such file or directory)
> error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: /Users/stephan/Software/lo/core/workdir/UnpackedTarball/python3/python-inst/@__________________________________________________OOO/LibreOfficePython.framework/Versions/3.8/lib/python3.8/lib-dynload/_testinternalcapi.cpython-3.8.so (No such file or directory)
> error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: /Users/stephan/Software/lo/core/workdir/UnpackedTarball/python3/python-inst/@__________________________________________________OOO/LibreOfficePython.framework/Versions/3.8/lib/python3.8/lib-dynload/_dbm.cpython-3.8.so (No such file or directory)
when the two jobs run in parallel
Change-Id: I6db18d7a6fa0ce177e88f8f714434acf9afe3ea5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115218
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
- align with most of the rest of config_host
- rename DISABLE_OPENSSL to ENABLE_OPENSSL
- make this configurable
Change-Id: Ic3b41fcdda38db66134939f12265e0da24833d60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114564
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
There is no longer any "m" in the name suffix. Adapt the names of the
ones we want to remove for macOS.
The idlelib and tkinter dylibs are no longer there at all.
Don't use the -f flag to the rm commands. Thus we will notice the next
time something we want to remove isn't actually there or has been
renamed. But sadly for some unknown reason we do need to use a *
wildcard in the .so names.
Fixes a problem caught by App Store review where the Python curses
module had not been removed as it should have been. (It uses
non-public APIs and can thus not be included.)
Change-Id: I51b9728cc9ca0a962908d3994e3a0ff8e4fa7f60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114372
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Signing them as executable code would require external attributes, and
those in turn break packaging into hfs+ dmg when building on apfs with
Big Sur.
It is not a new thing - the old Code Signing in Depth technote
https://developer.apple.com/library/archive/technotes/tn2206/_index.html
already reads:
"Store Python, Perl, shell, and other script files and other non-Mach-O
executables in your app's Contents/Resources directory. While it's
possible to sign such executables and store them in Contents/MacOS, this
is not recommended.
[…]
Put another way, a properly-signed app that has all of its files in the
correct places will not contain any signatures stored as extended
attributes."
The patch does exactly that for LO and the shipped python framework and
adds symlinks for the moved files.
Same applies for the Language pack applescript and the tarball - those
are also moved into Contents/Resources
Change-Id: Iab21e77b73f941248ca89c6e80703fdf67a1057c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109537
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
On macOS, for various reasons, we use a different approach than on
other platforms to construct the bundled Python.
Instead of explicitly listing what to include (out of what Python
contains and builds) (in ExternalPackage_python3.mk), after Python is
built, we remove stuff we don't want (in ExternalProject_python3.mk)
and then include everything left in the LibreOfficePython.framework
(in GeneratedPackage_python3.mk).
This fixes a problem in App Store review: For some reason the review
said that the setcchar() function from the ncurses library, used by
Python's curses module, is non-public. No idea why the (automated)
review picked on that function. As far as I see from the ncurses
header in the SDK, that function is no less public than the other
ncurses functions that the Python module uses.
But oh well, we don't actually ship the curses module anyway on other
platforms, so just drop it on macOS, too. And while at it, drop the
other unwanted ones, too. And any binary shared libraries for them.
Change-Id: Idecaf10a6fb1c59e8711095927f5699b8d2ec98e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107055
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107141
Tested-by: Tor Lillqvist <tml@collabora.com>
This has been suggested on IRC for testing fixes/avoiding regressions
when working on the GIL locking in PyUNO.
Change-Id: Ifda21a867b3c0c7db636a9ec950050012e4742de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106791
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
Adds three Windows gb_* variables:
- gb_MSBUILD_CONFIG_AND_PLATFORM can be passed as msbuild flags
- gb_MSBUILD_PLATFORM maps debug / release settings
- gb_MSBUILD_CONFIG maps the CPUTYPE to the default msbuild names
and converts the users in external projects.
Change-Id: Ie9b817721180d78d104db11c44241e4b3e46bba9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102701
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
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>
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>
The OpenSSL 1.1.1 release is currently the only supported version
and it already has the Windows Arm64 support I was looking for.
This change also explicitly enables thread support, which Python
depends on since release 3.7, which removed the --without-threads
build option. But the explicit OPENSSL_THREADS was just added in
3.8.4, so the old no-threads build fails now and was wrong since
probably much longer.
Change-Id: I61d94f966bc59407f213f4a81f0a49d0c05f8948
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98435
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...which had been introduced with 0f2f719ccd
"tdf#106324: Remove unnecessary test folder from LibreOfficePython framework",
but had apparently forgotten to touch the target file when done, so any make
target that would (indirectly) depend on it would keep rebuilding python3 et al.
Change-Id: I0ac3611383c82c4e91a1eaa02e4cf5db28d326fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93117
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This had originally been covered by dccf47b7f6
"Build python3 with debug flags if --enable-debug", which got broken by
eeeec33ada "merge --enable-selective-debuginfo
into --enable-symbols" (which removed the definition of
gb_Module_CURRENTMODULE_DEBUG_ENABLED without adapting its use here).
But looking again, setting OPT for workdir/UnpackedTarball/python3/configure.ac
based on our various flags doesn't seem to be such a good idea anyway: It is
used to specify a mixture of debuginfo (-g; which is set rather unconditionally,
so no need for us to cater for --enable-symbols here), optimization (-fwrapv,
-O*), and warning (-Wall) flags. So better let
workdir/UnpackedTarball/python3/configure.ac keep deciding for itself what flags
to set in OPT, and then just override via CFLAGS those that do not suite us.
(Where it appears to be a happy coincidence that the Python build system puts
CFLAGS after OPT, so the former can override the latter.)
(An alternative approach could have been to pass --with-pydebug based on e.g.
--enable-dbgutil, as the former (a) causes OPT to include -O0 rather than -O3,
and (b) is documented to change the ABI (see
workdir/UnpackedTarball/python3/configure.ac: "Py_DEBUG implies assertions, but
also changes the ABI."), so probably best fits --enable-dbgutil. However, at
least on Linux, --with-pydebug produces
workdir/UnpackedTarball/python3/libpython3.7dm.so rather than
workdir/UnpackedTarball/python3/libpython3.so, so would have required further
modifications. Also, in a Linux UBsan build, making ExternalProject_python3
would have started to cause some "applying zero offset to null pointer"
failures, but which would have been easy to fix.)
(I noticed the missing -O0 when I attached gdb to an instdir/program/python.bin
process and `py-bt` only showed "(frame information optimized out)" frames,
which this change fixes for --disable-optimized builds.)
Change-Id: I9583e60692ae7130377422062f3c6df9334d693f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92362
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(where 16.4 is currently the latest version of Visual Studio 2019 available at
<https://visualstudio.microsoft.com/downloads/>), see
<https://lists.freedesktop.org/archives/libreoffice/2020-February/084575.html>
"ESC meeting minutes: 2020-02-27": "Update baseline to VS2019 on master before
7.0 [...] check what’s the current patch level, require that? [...] no
objections"
The code from 4ea0059bca "VS detection: Fallback
to old registry check if vswhere failed" has been removed in accordance with its
comment "The below hack does not work for VS 2019 anyway, so should be removed
when upgrading baseline.
(Changing the comment "go to Start menu, open 'Visual Studio 2017', [...]"
regarding the installation of GNU Make from source is somewhat arbitrary, but
lets stick to the tradition of bumping that version number along with any build
baseline bump.)
Change-Id: Ic4fe8a3d347aa1748377f2d3205e302bff189b79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89699
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
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 b10be5d484)
Change-Id: Ibc20cf8cd3614cf9941b6970662bd930496776b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86493
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>
Xisco Fauli