This commit updates CI and configuration from wasi-sdk-25 to wasi-sdk-29
which was released recently. This notably includes stubs for pthreads
which all return errors, so some adjustment in logic is necessary to
retain knowledge that WASI cannot yet spawn threads for example.
This additionally increases the wasm stack allowance to 32MiB from 16MiB
to accomodate the `test_recursive_pickle` test in the
`test_functools.py` file. It looks like the Clang/LLVM update that
happened in wasi-sdk-29 relative to wasi-sdk-25 is likely the cause of
this where presumably functions have more locals than before and/or a
slightly adjusted stack space requirement which overflows the stack.
Android has Linux's statx, but MACHDEP is "android" on Android, so
configure doesn't check for statx on Android. Base the check for statx
on ac_sys_system instead, which is "Linux-android" on Android, "Linux"
on other Linux distributions, and "AIX" on AIX (which has an
incompatible function named statx).
* fix: add missing `build-details.json` step for building wasm
Signed-off-by: Ho Kim <ho.kim@ulagbulag.io>
* gh-138489: Add missing build-details.json step for building wasm
Signed-off-by: Ho Kim <ho.kim@ulagbulag.io>
* Update Makefile.pre.in
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
---------
Signed-off-by: Ho Kim <ho.kim@ulagbulag.io>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
A runtime check is needed to support cross-compiling.
Remove the _Py_NORMALIZE_CENTURY macro.
Remove _pydatetime.py's _can_support_c99.
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* Add OpenSSL 3.5.2 definitions to Modules/_ssl_data_35.h (moved from Modules/_ssl_data_34.h)
* Demote OpenSSL 3.1 to "old", remove it from CI
* Update all OpenSSL versions to latest patchlevel in CI config and multissltests defaults
* Add OpenSSL 3.5.2 to CI configuration and multissltests default list
* Fix a typo in the argument parser description of multissltests.py
The `Modules/hashlib.h` helper file is now removed and split into multiple files:
* `Modules/_hashlib/hashlib_buffer.[ch]` -- Utilities for getting a buffer view and handling buffer inputs.
* `Modules/_hashlib/hashlib_fetch.h` -- Utilities used when fetching a message digest from a digest-like identifier.
Currently, this file only contains common error messages as the fetching API is not yet implemented.
* `Modules/_hashlib/hashlib_mutex.h` -- Utilities for managing the lock on cryptographic hash objects.
* gh-134632: Fix `build-details.json` to use `INCLUDEPY` path
Fix ``build-details.json`` generation to use ``INCLUDEPY``, in order to
reference the ``pythonX.Y`` subdirectory of the include directory, as
required in :pep:`739`, instead of the top-level include directory.
* test_build_details: Add tests for the c_api section
* test_build_details: Expect pkgconfig for CPython unconditionally
* Replace _Py_ALIGN_AS(V) by _Py_ALIGNED_DEF(N, T)
This is now a common façade for the various `_Alignas` alternatives,
which behave in interesting ways -- see the source comment.
The new macro (and MSVC's `__declspec(align)`) should not be used
on a variable/member declaration that includes a struct declaraton.
A workaround is to separate the struct definition.
Do that for `PyASCIIObject.state`.
* Specify minimum PyGC_Head and PyObject alignment
As documented in InternalDocs/garbage_collector.md, the garbage collector
stores flags in the least significant two bits of the _gc_prev pointer
in struct PyGC_Head. Consequently, this pointer is only capable of storing
a location that's aligned to a 4-byte boundary.
Encode this requirement using _Py_ALIGNED_DEF.
This patch fixes a segfault in m68k, which was previously investigated
by Adrian Glaubitz here:
https://lists.debian.org/debian-68k/2024/11/msg00020.htmlhttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087600
Original patch (using the GCC-only Py_ALIGNED) by Finn Thain.
Co-authored-by: Finn Thain <fthain@linux-m68k.org>
Co-authored-by: Victor Stinner <vstinner@python.org>
Co-authored-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Previously the module would fail to load because the `alloca()` symbol
was undefined. Now we check for GCC/Clang builtins for systems who do
not define `alloca()` in headers.
Fix `build-details.json` generation to use the correct `c_api.headers`
key as defined in PEP 739, instead of `c_api.include`.
Co-authored-by: Filipe Laíns 🇵🇸 <lains@riseup.net>
When built on a MIPS architecture, `_MIPS_SIM` is used to determine
architecture specifics. The value is expected to match either
`_ABIO32`, `_ABIN32` or `_ABI64`.
In `gcc` config/mips/mips.h these values are defined as compiler
`builtin_define` inside of a switch/case. That means, mips64el and
mips64 architectures know about `_ABI64` but don't know about `_ABIO32`
and `_ABIN32`. In turn, when CPython tries to use them in comparison,
they may be undefined identifiers.
In default compiler behavior, the undefined identifier will be
evaluated as zero, and it will not match `_MIPS_SIM`. However, the
issues pop up when `-Wundef` (or, even worse, `-Werror=undef`) compiler
flag is enabled. Then suddenly it's visible as a warning or error.
Change the default LTO flags on GCC to not pass -flto-partition=none, and allow parallelization of LTO. This has a multiple factor speedup for LTO build times on GCC, with no noticeable loss in performance.
On newer make and newer GCC, this passes the jobserver automatically to GCC (or more like GCC grabs it from the env vars).
On older make, this will have benign warnings about serial compilation. It's safe to ignore them.
Use the standard `__ARM_ARCH` macro, which is supported by GCC and Clang.
The branching logic for of `__ARMEL__` has been removed so if the target
architecture supports v7+ instructions, a yield is emitted, otherwise a nop
is emitted. This covers both big and little endian scenarios.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
When using --with-dtrace the resulting object file could be missing
specific CFLAGS exported by the build system due to the systemtap
script using specific defaults.
Exporting the CC and CFLAGS variables before the dtrace invocation
allows us to properly apply CFLAGS exported by the build system
even when cross-compiling.
The fix does not affect the dtrace invocation on Solaris/macOS.
