gh-133779: Revert Windows generation of pyconfig.h and go back to a static header.#133966
Conversation
…to a static header. This means that extension builders will need to specify Py_GIL_DISABLED if they want to link to the free-threaded builds.
zooba
added
needs backport to 3.14
|
!buildbot .windows. |
|
🤖 New build scheduled with the buildbot fleet by @zooba for commit 142b60a 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F133966%2Fmerge The command will test the builders whose names match following regular expression: The builders matched are:
|
|
@encukou You'll probably be interested in the test_cext failure, as it relates to In short, I think it's one we can suppress for our entire header, which I'll do here to unblock this release blocking PR. You may have ideas/preferences about how best to structure that sort of thing, so feel free to change it later. (FWIW, my guess is that the test previously wasn't handling Py_GIL_DISABLED properly and now is, since the only use of |
zooba
added
the
🔨 test-with-buildbots
|
🤖 New build scheduled with the buildbot fleet by @zooba for commit 7a8d6ab 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F133966%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
bedevere-bot
removed
the
🔨 test-with-buildbots
|
Thanks @zooba for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14. |
|
Sorry, @zooba, I could not cleanly backport this to |
…to a static header. (pythonGH-133966) Extension builders must specify Py_GIL_DISABLED if they want to link to the free-threaded builds. This was usually the case already, but this change guarantees it in all circumstances.
|
GH-134211 is a backport of this pull request to the 3.14 branch. |
|
@zooba, looks like these changes may have broken JIT builds (https://github.com/python/cpython/actions/runs/15116899287/job/42490545690?pr=134240). I think the new generated JIT stencils directory doesn't exist, so it can't be used as a working directory in the build scripts. Further, the Python script that runs expects |
|
Oh, I see. It looks like |
|
Would it be too difficult to go back to copying |
I'm going to start by saying "yes", because we went at least a decade with a static config file, and the experimental free-threading build is the only reason we stopped. So we're back to "you'd better have a really strong reason to complicate the build system", and I don't think this is it. |
… to a static header. (GH-133966) Extension builders must specify Py_GIL_DISABLED if they want to link to the free-threaded builds. This was usually the case already, but this change guarantees it in all circumstances.
I am, see #135183. Sorry for the delay :) |
…to a static header. (pythonGH-133966) Extension builders must specify Py_GIL_DISABLED if they want to link to the free-threaded builds. This was usually the case already, but this change guarantees it in all circumstances.
…to a static header. (pythonGH-133966) Extension builders must specify Py_GIL_DISABLED if they want to link to the free-threaded builds. This was usually the case already, but this change guarantees it in all circumstances.
…n Windows Free-threaded (PEP 703) extensions must be compiled with `Py_GIL_DISABLED` so their `PyObject` / `PyTypeObject` header layout matches the free-threaded interpreter. Without it the 16-byte GIL header is compiled against the 32-byte free-threaded runtime, shifting every `PyTypeObject` slot down 16 bytes: the extension reads `tp_alloc` where the runtime stores `tp_dictoffset` and calls that value, faulting on `import` -- an execute/NX access violation in `pybind11::detail::make_static_property_type`. The macro is not defined automatically. On Linux and macOS the `configure`-generated `pyconfig.h` defines it; the gap is Windows-only. CPython 3.14+ dropped it from the static Windows `pyconfig.h` (python/cpython#133966). CMake's `FindPython` adds it via `Python_DEFINITIONS` for a free-threaded *release* interpreter, but misses a free-threaded *debug* one -- an upstream CMake bug: it files the debug import library `python314t_d.lib` in the release slot (`Python_LIBRARY_RELEASE`), but its free-threaded test only matches a `...t.lib` suffix, so the `_d` suffix slips through. So only the free-threaded debug (`td`) build on Windows lacks it. Probe the interpreter (`sysconfig`) directly instead and define the macro on the `_C` target. Supporting changes: - setup.py: emit the MSVC linker `.pdb` next to the `.pyd` (package directory) on Windows so a crash dump can be symbolised. - CMakeLists.txt: log the `FindPython` library/definition resolution for free-threaded diagnosis. - tests.yml, tests-with-pydebug.yml: smoke-test `import optree` immediately after install (under `cdb` on Windows) and fail the job on any coredump.
4 participants
This means that extension builders will need to specify Py_GIL_DISABLED if they want to link to the free-threaded builds.
python314t.libon non-threaded python #133779