Windows wheels are not self-contained: _internals.pyd needs unbundled MinGW runtime DLLs (libstdc++-6, libgcc_s_seh-1)

[stoiver]

The win_amd64 wheels (meshpy 2025.1.1) are MinGW-built and don't bundle the MinGW runtime DLLs, so importing meshpy fails on a clean Windows Python:

ImportError: DLL load failed while importing _internals: The specified module could not be found.

Evidence

• The wheel ships meshpy/_internals.cp312-win_amd64.dll.a — a GNU/MinGW import library, i.e. a MinGW build.
• The import table of meshpy/_internals.cp312-win_amd64.pyd (via pefile) lists:
  • libgcc_s_seh-1.dll
  • libstdc++-6.dll
  • and only system DLLs otherwise (KERNEL32.dll, api-ms-win-crt-*, python312.dll).
• None of the MinGW runtime DLLs are bundled inside the wheel.

So on a clean Windows Python (no MinGW on PATH), libstdc++-6.dll / libgcc_s_seh-1.dll can't be found and _internals fails to load.

Reproduce

In a clean virtualenv on Windows (no MinGW on PATH):

pip install meshpy==2025.1.1
python -c "import meshpy.triangle"
# ImportError: DLL load failed while importing _internals: The specified module could not be found.

Impact

Breaks pip install meshpy on Windows for anyone without a MinGW toolchain on PATH. In particular it breaks pip install anuga on Windows, since ANUGA depends on meshpy as its mesh generator.

Suggested fix

Run delvewheel repair on the Windows wheels in the release build to bundle the MinGW runtime DLLs (libstdc++-6.dll, libgcc_s_seh-1.dll, and libwinpthread-1.dll), making the wheels self-contained — the Windows equivalent of auditwheel (Linux) and delocate (macOS).

Environment

• meshpy 2025.1.1
• Python 3.12
• Windows (GitHub windows-latest runner)

[inducer]

Thanks for the report. I'm very much not a Windows person, I don't even have a machine to test. Could you prepare a PR?

[stoiver]

@inducer I'm not much of a windows person either, but was just testing the import of anuga on a clean windows environment via github CI and ran into the problem first for anuga (which also uses MinGW because of the openmp support) and then when anuga imported meshpy. So with the help of claude, I have just create a PR#151

[stoiver]

Status: fixed on main, not yet on PyPI.

After #152 bumped cibuildwheel to 4.0.0 (which auto-runs delvewheel), the Windows wheels built from main are now self-contained — I checked a fresh meshpy-2025.1.1-cp312-cp312-win_amd64.whl from the "Build wheels" CI artifact and it bundles the runtime DLLs under meshpy.libs/:

• libgcc_s_seh-1-*.dll
• libstdc++-6-*.dll
• libwinpthread-1-*.dll

(plus a DELVEWHEEL marker in dist-info). So import meshpy._internals should work on a clean install of these wheels. #151 (the manual delvewheel PR) is now redundant and has been closed.

However, the wheels currently on PyPI are still the pre-fix 2025.1.1 build (no meshpy.libs/, no DELVEWHEEL), and since the version string is unchanged they can't be replaced in place. A new release is needed to ship the self-contained wheels to PyPI before downstream pip install consumers pick up the fix. Worth keeping this issue open until that release is out.

[inducer]

https://github.com/inducer/meshpy/releases/tag/v2026.1

Should arrive on the package index once this run completes: https://github.com/inducer/meshpy/actions/runs/27216330146

[stoiver]

Yes the package has made it to PyPI and our code passes all the tests (which depended on a pip install meshpy on windows).

Thanks for your great work.