Problem building pyodide wheels with cibuildwheel tool when actions/setup-python sets the same Python version as the Pyodide Python version

[andyfaff]

Description

I'm trying to modify numpy/numpy-releases to build the numpy wheels for pyodide. numpy-releases is going to be the minimal repo for build artifacts. We try to limit exposure to a wider spread of github actions, apart from those absolutely necessary.

One step uses actions/setup-python to install Python. The next step uses a python -m cibuildwheel invocation to build the relevant wheel. However, there are issues building the cp312-pyodide_wasm32/cp313-pyodide_wasm32 candidates.

I think there is a path somewhere that is being set up incorrectly. If actions/setup-python installs python3.12 then the cp312-pyodide_wasm32 entry fails during the build process, but the cp313-pyodide_wasm32 succeeds. If actions/setup-python installs python3.13 then the cp313-pyodide_wasm32 entry fails, but the cp312_pyodide_wasm32 succeeds.
If I do a pre-release install of python3.14 then both the cp312 and cp313 wheels build successfully.

Note that using the pypa/cibuildwheel action works to build both cp312 and cp313, it's only the command line call of python -m cibuildwheel that doesn't work.

The reason I think it's a path issue is because the fail has a build error along the lines of:

  /opt/hostedtoolcache/Python/3.13.7/x64/include/python3.13/pyport.h:399:2: error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
    399 | #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."

which means that there's an bitness incompatibility somewhere. e.g. the headers might be picked up from one Python install but the libraries might be from another.

It's not clear to me if this issue belongs in cibuildwheel or in actions/setup-python. The CI config below is for the PR I'm trying make for the pyodide build. There's a lot of commits from me doing the fault finding above.

Build log

https://github.com/numpy/numpy-release/actions/runs/17115057979/job/48544209219

CI config

numpy/numpy-release#7

[agriyakhetarpal]

I think there is a path somewhere that is being set up incorrectly. If actions/setup-python installs python3.12 then the cp312-pyodide_wasm32 entry fails during the build process, but the cp313-pyodide_wasm32 succeeds. If actions/setup-python installs python3.13 then the cp313-pyodide_wasm32 entry fails, but the cp312_pyodide_wasm32 succeeds.
If I do a pre-release install of python3.14 then both the cp312 and cp313 wheels build successfully.

Hi! I wonder if this issue stems from the fact that actions/setup-python makes the PKG_CONFIG_PATH environment variable available: https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md#using-update-environment-flag. We could try unsetting it.

I might be mistaken, but I think this issue isn't something that can be fixed within cibuildwheel. Unfortunately, NumPy seems to be affected by it.

[agriyakhetarpal]

When the build works (different Python versions for the WASM wheel build and for setup-python), I notice that the sizes of Py_intptr_t and PY_LONG_LONG are 4 and 8, respectively – however, a failing build has both of them as -1; following from the definitions in pyport.h. This indeed means that the wrong Python gets picked up. :(

[joerick]

I wonder if this issue stems from the fact that actions/setup-python makes the PKG_CONFIG_PATH environment variable available: https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md#using-update-environment-flag. We could try unsetting it.

I'm not totally following why we wouldn't be able to unset that env var - it seems to me that pyodide is sufficiently strange a target that we could assume in cibuildwheel that the environment variables from the system aren't relevant, and just delete them?

[agriyakhetarpal]

I wonder if this issue stems from the fact that actions/setup-python makes the PKG_CONFIG_PATH environment variable available: actions/setup-python@main/docs/advanced-usage.md#using-update-environment-flag. We could try unsetting it.

I'm not totally following why we wouldn't be able to unset that env var - it seems to me that pyodide is sufficiently strange a target that we could assume in cibuildwheel that the environment variables from the system aren't relevant, and just delete them?

I suppose it won't hurt for us to try! I was just worried that unsetting PKG_CONFIG_PATH could interfere with package builds, but if they rely on pkg-config, they will set it back anyway.