Wheels 0.17.1.post4#1904
Merged
Merged
Conversation
ax3l
commented
Jun 28, 2026
…TOR) The win64 openpmd_api wheel access-violates at `import openpmd_api` (NULL read in MSVCP140!Mtx_destroy) -- the VS 2022 17.10 std::mutex constexpr-constructor ABI break. The wheel --excludes msvcp*.dll, so the SYSTEM msvcp140.dll runs and can predate the build toolset's STL, which then NULL-derefs in Mtx_destroy. Surfaced co-loaded under the ImpactX wheel's win64 test: with the same fix added to the impactx build, amrex and impactx now import cleanly and the crash moved to the openpmd_api dependency -- which needs the identical fix. Add /D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR to the Windows CXXFLAGS to revert to the non-constexpr constructor, ABI-compatible with any msvcp140. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…at too The std::mutex ABI define is already in CIBW_ENVIRONMENT_WINDOWS (the central wheel build); set it in the Windows dependency builder as well so ADIOS2 (and any other C++ dependency) is built with the same non-constexpr std::mutex ABI as openPMD-api. Since we --exclude msvcp*.dll from the wheel, this keeps the whole toolchain consistent and portable against any system msvcp140.dll (VS 2022 17.10 made the ctor constexpr -> otherwise a NULL deref in Mtx_destroy). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…E=2) library_builders.sh already builds the wasm zlib/HDF5 with -fvisibility=hidden (the DSO-local half). Add the complementary link-time half as a source patch: python-wasm-side-module.patch adds an EMSCRIPTEN branch to the co-load block (from python-hide-symbols.patch) that links the extension with -sSIDE_MODULE=2 and -sEXPORTED_FUNCTIONS=_PyInit_openpmd_api_cxx, so Pyodide no longer whole- archives and re-exports the bundled HDF5. Neither half fixes the co-load alone. Ports the dev fix openPMD#1903 (validated green there: the co-load probe + full Python suite run with a second HDF5, h5py, co-loaded). Applied in COMMON_PATCHES right after python-hide-symbols.patch, whose block it extends. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…d patch - setup.py version 0.17.1.post3 -> 0.17.1.post4 (rename the setup-py-version patch to match; update COMMON_PATCHES). - Regenerate python-wasm-side-module.patch so the applied CMakeLists co-load block matches openPMD-api#1903's current version (refined comment wording, no file-path reference, bare EMSCRIPTEN branch). Verified it applies cleanly after python-hide-symbols.patch and reproduces the openPMD#1903 block byte-for-byte. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ax3l
commented
Jul 2, 2026
Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja>
The .readthedocs.yml exit-183 skip never ran: build.tools.python "3.14" is not a supported Read the Docs build tool, so config validation failed and the per-PR RTD build errored (red check) instead of cancelling. post_checkout (exit 183) runs before the Python environment is created, so any valid version works -- use 3.12 so the config validates and the build cancels cleanly on the wheels branch. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…tion) The previous .readthedocs.yml (build.jobs.post_checkout: exit 183, with no sphinx/mkdocs/build.commands) was rejected at config parse time: the build failed right after `cat .readthedocs.yml`, before post_checkout ran, so exit 183 never fired and RTD posted a red check on every wheels-branch PR. The python version was a red herring -- 3.14 and 3.12 failed identically. Base the skip on dev's working config (add sphinx.configuration, use dev's os/python) so it validates; post_checkout's exit 183 then cancels the build before sphinx is read, and RTD reports the PR check as success (a cancelled build is a green check, per RTD docs). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
wheelsfor good_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR(CXXFLAGS)VS 2022 17.10 made
std::mutex's constructor constexpr, leaving its internals NULL until first use. We--exclude msvcp*.dllfrom the wheel, so the SYSTEMmsvcp140.dllruns; if it predates 17.10 it NULL-derefs inMtx_destroy->import openpmd_apiaccess-violates on win64 (surfaced when co-loaded under the ImpactX wheel's test). The define reverts to the non-constexpr constructor, ABI-compatible with anymsvcp140.