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>
...to avoid
> [build CHK] CustomTarget/postprocess/check_dynamic_objects/check.done
> instdir/program/python-core-3.11.11/lib/lib-dynload/_lzma.cpython-3.11d.so has suspicious NEEDED: liblzma.so.5
as seen at least when building on a Fedora 41 machine that happens to have
xz-devel-5.6.2-2.fc41.x86_64 installed (so that Python's configure detects
have_liblzma=yes).
The _lzma library had been added to external/python3/ExternalPackage_python3.mk
in 892c0d2ef0 "python3: update
python3_EXTENSION_MODULES", but without giving any rationale. (It had
previously been removed there with c2e4e74138
"Python3.5: Remove external dependencies: readline and lzma".)
Change-Id: I4afe9fb08891dda116f115dac7b2f948aac84e06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180194
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...when generating Python/deepfreeze/deepfreeze.c during the build of
ExternalProject_python3 after 50524481b3 "Python:
upgrade to 3.11.11 (master only)",
> Objects/dictobject.c:1500:40: runtime error: load of misaligned address 0x555853494d81 for type 'PyDictUnicodeEntry *', which requires 8 byte alignment
> 0x555853494d81: note: pointer points here
> 00 00 00 ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ^
> #0 in dictresize at workdir/UnpackedTarball/python3/Objects/dictobject.c:1500:21
> #1 in dict_merge at workdir/UnpackedTarball/python3/Objects/dictobject.c:2880:17
> #2 in _PyDict_MergeEx at workdir/UnpackedTarball/python3/Objects/dictobject.c:3003:12
> #3 in _PyEval_EvalFrameDefault at workdir/UnpackedTarball/python3/Python/ceval.c:3432:17
> #4 in _PyEval_EvalFrame at workdir/UnpackedTarball/python3/./Include/internal/pycore_ceval.h:73:16
> #5 in _PyEval_Vector at workdir/UnpackedTarball/python3/Python/ceval.c:6434:24
> #6 in _PyFunction_Vectorcall at workdir/UnpackedTarball/python3/Objects/call.c:393:16
> #7 in _PyObject_FastCallDictTstate at workdir/UnpackedTarball/python3/Objects/call.c:141:15
> #8 in _PyObject_Call_Prepend at workdir/UnpackedTarball/python3/Objects/call.c:482:24
> #9 in slot_tp_init at workdir/UnpackedTarball/python3/Objects/typeobject.c:7855:15
> #10 in type_call at workdir/UnpackedTarball/python3/Objects/typeobject.c:1103:19
> #11 in _PyObject_MakeTpCall at workdir/UnpackedTarball/python3/Objects/call.c:214:18
> #12 in _PyObject_VectorcallTstate at workdir/UnpackedTarball/python3/./Include/internal/pycore_call.h:90:16
> #13 in PyObject_Vectorcall at workdir/UnpackedTarball/python3/Objects/call.c:299:12
> #14 in _PyEval_EvalFrameDefault at workdir/UnpackedTarball/python3/Python/ceval.c:4769:23
> #15 in _PyEval_EvalFrame at workdir/UnpackedTarball/python3/./Include/internal/pycore_ceval.h:73:16
> #16 in _PyEval_Vector at workdir/UnpackedTarball/python3/Python/ceval.c:6434:24
> #17 in PyEval_EvalCode at workdir/UnpackedTarball/python3/Python/ceval.c:1148:21
> #18 in run_eval_code_obj at workdir/UnpackedTarball/python3/Python/pythonrun.c:1741:9
> #19 in run_mod at workdir/UnpackedTarball/python3/Python/pythonrun.c:1762:19
> #20 in pyrun_file at workdir/UnpackedTarball/python3/Python/pythonrun.c:1657:15
> #21 in _PyRun_SimpleFileObject at workdir/UnpackedTarball/python3/Python/pythonrun.c:440:13
> #22 in _PyRun_AnyFileObject at workdir/UnpackedTarball/python3/Python/pythonrun.c:79:15
> #23 in pymain_run_file_obj at workdir/UnpackedTarball/python3/Modules/main.c:360:15
> #24 in pymain_run_file at workdir/UnpackedTarball/python3/Modules/main.c:379:15
> #25 in pymain_run_python at workdir/UnpackedTarball/python3/Modules/main.c:605:21
> #26 in Py_RunMain at workdir/UnpackedTarball/python3/Modules/main.c:684:5
> #27 in main at workdir/UnpackedTarball/python3/Programs/_bootstrap_python.c:109:12
Change-Id: I0bacef11b5874bca6104516a206076a0505528ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180037
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
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>
Since a1295cb177
"python: upgrade to 3.10.14 (master only)"
Now it fails with
Traceback (most recent call last):
File "/home/tdf/lode/jenkins/workspace/lo_callgrind_linux/workdir/UnpackedTarball/lxml/setup.py", line 23, in <module>
import setupinfo
File "/home/tdf/lode/jenkins/workspace/lo_callgrind_linux/workdir/UnpackedTarball/lxml/setupinfo.py", line 7, in <module>
from distutils.command.build_ext import build_ext as _build_ext
File "/home/tdf/lode/jenkins/workspace/lo_callgrind_linux/instdir/program/python-core-3.10.14/lib/distutils/command/build_ext.py", line 13, in <module>
from distutils.sysconfig import customize_compiler, get_python_version
File "/home/tdf/lode/jenkins/workspace/lo_callgrind_linux/instdir/program/python-core-3.10.14/lib/distutils/sysconfig.py", line 58, in <module>
warnings.warn(
DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
make[1]: *** [/home/tdf/lode/jenkins/workspace/lo_callgrind_linux/external/lxml/ExternalProject_lxml.mk:26: /home/tdf/lode/jenkins/workspace/lo_callgrind_linux/workdir/ExternalProject/lxml/build] Error 1
Change-Id: I9000018390b31a65a30ef87d0c500872fc6c9343
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170069
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Since a1295cb177
"python: upgrade to 3.10.14 (master only)"
Some builds started to fail with
Traceback (most recent call last):
File "/home/tdf/lode/jenkins/workspace/lo_callgrind_linux/workdir/UnpackedTarball/lxml/setup.py", line 15, in <module>
from setuptools import setup
ModuleNotFoundError: No module named 'setuptools'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/tdf/lode/jenkins/workspace/lo_callgrind_linux/workdir/UnpackedTarball/lxml/setup.py", line 17, in <module>
from distutils.core import setup
File "/home/tdf/lode/jenkins/workspace/lo_callgrind_linux/instdir/program/python-core-3.10.14/lib/distutils/__init__.py", line 19, in <module>
warnings.warn(_DEPRECATION_MESSAGE,
DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
make[1]: *** [/home/tdf/lode/jenkins/workspace/lo_callgrind_linux/external/lxml/ExternalProject_lxml.mk:26: /home/tdf/lode/jenkins/workspace/lo_callgrind_linux/workdir/ExternalProject/lxml/build] Error 1
The problem is that python 3.10 doesn't bundle setuptools so
it's not possible to replace it at the moment
Change-Id: I9a9d077b51f49e912dab4941efe8751c2fcc76e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170068
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Downloaded from https://www.python.org/ftp/python/3.9.19/Python-3.9.19.tar.xz
* python-3.8-msvc-sdk.patch.1 is no longer needed
* Comment out deprecated warnings for now:
C:/cygwin64/home/tdf/jenkins/workspace/gerrit_windows/pyuno/source/module/pyuno_util.cxx(42): error C2220: the following warning is treated as an error
C:/cygwin64/home/tdf/jenkins/workspace/gerrit_windows/pyuno/source/module/pyuno_util.cxx(42): warning C4996: 'PyUnicode_FromUnicode': deprecated in 3.3
C:/cygwin64/home/tdf/jenkins/workspace/gerrit_windows/pyuno/source/module/pyuno_util.cxx(64): warning C4996: 'PyUnicode_AsUnicode': deprecated in 3.3
Change-Id: Iaa358ffaaea63cf6ec47914759d0469e70e1cc65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168551
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
which can happen if stdin was closed and the next
open was of a dir.
Later python checks for is_valid_fd, but an invalid fd
is not fatal for stdin, etc and it just return an empty
stdin wrapper, so move this check lower and do the same
for a dir.
Change-Id: Iaf8a48927b49408577ae7a781dfc6e0255a940cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165327
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
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>
patch out using IPC::Cmd instead of requiring adding it
to build-time dependencies
for mysterious:
The system cannot find the path specified.
NMAKE : fatal error U1077: '""C:\PROGRA~2\MIB055~1\2019\COMMUN~1\VC\Tools\MSVC\1429~1.301\bin\Hostx64\x86\cl.exe' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x86\nmake.exe"' : return code '0x2'
Stop.
include fix from https://github.com/openssl/openssl/issues/18823
and for
move /Y crypto/aes/aes-586.asm.i crypto/aes/aes-586.asm
The system cannot find the path specified.
NMAKE : fatal error U1077: 'move' : return code '0x1'
add own patch to use mv and rm for move and del
Change-Id: I071750e20efd0931ea1c5c3b49e7a5173c7283f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139641
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
..when building ExternalProject_python3 with Clang -fsanitize=thread,
> WARNING: ThreadSanitizer: destroy of a locked mutex (pid=973799)
> #0 in AnnotateRWLockDestroy at /home/sbergman/github.com/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interface_ann.cpp:184:3 (workdir/UnpackedTarball/python3/python +0x498460)
> #1 in recreate_gil at workdir/UnpackedTarball/python3/Python/ceval_gil.h:138:5 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0xe84aa9)
> #2 in _PyEval_ReInitThreads at workdir/UnpackedTarball/python3/Python/ceval.c:350:5 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0xe847c7)
> #3 in PyOS_AfterFork_Child at workdir/UnpackedTarball/python3/./Modules/posixmodule.c:469:5 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x1163dbd)
> #4 in os_fork_impl at workdir/UnpackedTarball/python3/./Modules/posixmodule.c:6253:9 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x11adcad)
> #5 in os_fork at workdir/UnpackedTarball/python3/./Modules/clinic/posixmodule.c.h:2750:12 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x117b481)
> #6 in cfunction_vectorcall_NOARGS at workdir/UnpackedTarball/python3/Objects/methodobject.c:463:24 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x9db7e1)
> #7 in _PyObject_Vectorcall at workdir/UnpackedTarball/python3/./Include/cpython/abstract.h:127:11 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0xf0225e)
> #8 in call_function at workdir/UnpackedTarball/python3/Python/ceval.c:4963:13 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0xef3f4a)
> #9 in _PyEval_EvalFrameDefault at workdir/UnpackedTarball/python3/Python/ceval.c:3469:23 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0xedc5d8)
[...]
> #143 in pymain_run_python at workdir/UnpackedTarball/python3/Modules/main.c:610:21 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x1149f6c)
> #144 in Py_RunMain at workdir/UnpackedTarball/python3/Modules/main.c:689:5 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x11495e9)
> #145 in pymain_main at workdir/UnpackedTarball/python3/Modules/main.c:719:12 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x114a299)
> #146 in Py_BytesMain at workdir/UnpackedTarball/python3/Modules/main.c:743:12 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x114a30d)
> #147 in main at workdir/UnpackedTarball/python3/./Programs/python.c:16:12 (workdir/UnpackedTarball/python3/python +0x4d00f8)
Assuming that the GIL is always locked before the fork, better tell TSan about a
fake RELEASED before telling it about a fake DESTROY, to keep TSan's model
consistent.
Change-Id: I6c68d7e415aa0ffc3047e5a5c4c4aca6b0cce8cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130985
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
Christian Lohmaier