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>
...since
<https://github.com/llvm/llvm-project/commit/a921d2d2fb46b898794091e7410426c518a4f0cc>
"[Driver] Add -print-multiarch", which causes an issue when building
ExternalProject_python3 on macOS:
> checking build system type... x86_64-apple-darwin19.6.0
> checking host system type... x86_64-apple-darwin19.6.0
[...]
> checking for the platform triplet based on compiler characteristics... darwin
configure: error: internal configure error for the platform triplet, please file a bug report
> make[1]: *** [/Users/stephan/Software/lo/core/external/python3/ExternalProject_python3.mk:80: /Users/stephan/Software/lo/core/workdir/ExternalProject/python3/build] Error 1
as workdir/UnpackedTarball/python3/configure.ac computes PLATFORM_TRIPLET as
"darwin", and instead of computing MULTIARCH as empty (as `$CC
--print-multiarch` used to just print
> clang: error: unsupported option '--print-multiarch'
> clang: error: no input files
to stderr), it now computes it as e.g. "x86_64-apple-darwin19.6.0" (or whatever
-target is explicitly set to in $CC), so the check that they have equal values
if they are bot nonempty fails now when building against Clang 13 trunk. (This
is not yet an issue with any Apple Clang version, though.)
Until this is eventually fixed upstream at <https://github.com/python/cpython>,
just keep pretending that `clang --print-multiarch` would cause no stdout output
on macOS when determining MULTIARCH.
Change-Id: Ic1b27c6791b327d5709a9d61a6d675c3fa8989bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115219
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
The Windows platform is called Arm64. But now that the ID for Mac
is also going to be renamed from arm64 to aarch64, this get's rid
of the arm64 as the UNO identifier and user in gbuild, just like
on all other Arm64 platforms.
Change-Id: I60a7eafd04b426f17b6e41ad9a09e6405c0d4173
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112973
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
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>
That seems to happen in a sandboxed process on macOS, at least. This
caused an apparent hang when invoking Python, for instance simply
through Tools > Macros > Run Macro... .
Change-Id: I6bc055b44f298251ed596084538b98442c215fce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107013
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
...that happen when building ExternalProject_python3 itself after
12142490cd "Enable Python Py_DEBUG setting when
built with --enable-dbgutil on Linux":
For one, silence
> Modules/posixmodule.c:14395:9: runtime error: left shift of 34 by 26 places cannot be represented in type 'int'
> #0 in all_ins at workdir/UnpackedTarball/python3/./Modules/posixmodule.c:14395:9
where at least my kernel-headers-5.9.9-200.fc33.x86_64
/usr/include/linux/memfd.h has
> #define MFD_HUGE_16GB HUGETLB_FLAG_ENCODE_16GB
and /usr/include/asm-generic/hugetlb_encode.h has
> #define HUGETLB_FLAG_ENCODE_16GB (34 << HUGETLB_FLAG_ENCODE_SHIFT)
For another (and as predicted in 29d47d22c4 "Fix
passing --disable-optimized into external/python3": "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"),
silence
> Objects/listobject.c:551:24: runtime error: applying zero offset to null pointer
> #0 in list_concat at workdir/UnpackedTarball/python3/Objects/listobject.c:551:24
Change-Id: I0523cd35e393000c8e67629a0522b2db1d8c16f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106984
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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
There is no /usr/lib/libz.dylib any longer in macOS 11.
No idea whether it works (especially on arm64), but that is another
issue.
Change-Id: I92ac0c500388730eca0be4766f07b1af2d2808e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105897
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
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>
Christian Lohmaier