meson-python link.exe issue since 3.3.0 release

Description

I tried to update my CI scripts to use the latest (3.3.0) cibuildwheel release, but somehow it seems to mess with the way meson finds msvc link.exe. I tried several cibuildwheel versions:

3.3.0 ❌
3.2.1 ✅
3.1.1 ✅
2.23.3 ✅

I tried look quickly in the release diff between 3.3.0 and 3.2.1 I didn't see anything obvious.
I believe I also have the correct Meson setup.

Build log

https://github.com/SciQLop/SciQLopPlots/actions/runs/19391928744/job/55486608055

CI config

No response

v3.2.1...v3.3.0

I see #2630; That's now modifying the path, rather than just pointing at cibuildwheel. If there was anything else in that location, that would get exposed too. However, it seems to be pretty carefully exposing only the binaries. I don't think that change is actually needed, since we use uv.find_uv_bin() to find uv if it's installed alongside us, but I don't see how that would have broken anything.

The windows.py file didn't really change in a way that could affect this.

Build dep pinning changes shouldn't affect meson-python.

Other than that, just normal dependency updates, which I wouldn't think would affect a Windows build. I'd be curious to see a build from just before / just after #2630.

Better yet, could you try #2673 on your workflow? Just use @henryiii/fix/simpleraction instead of @3.2.1.

@henryiii

@henryiii thanks a lot for your help, I started a build here, it seems to work so far.

Test CIBW fix

@henryiii

@henryiii I ran into the same problem as jeandet on my project.

Using your custom branch fixes the problem. Tested here: pygame-community/pygame-ce#3655

I think I'm coming across a similar problem here where 3.3.x somehow changes the env so that setuptools is no longer able to detect the Windows SDK paths and thus won't include them in the -I include dirs for cl.exe.

Working run with v3.2.1 - https://github.com/pythongssapi/python-gssapi/actions/runs/21275731526/job/61234998635

We can see that the first cl.exe command being run is

"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\bin\HostX86\x64\cl.exe" /c /nologo /O2 /W3 /GL /DNDEBUG /MD -Igssapi/raw -Igssapi\raw -IC:\Users\runneradmin\AppData\Local\Temp\build-env-w6qezc8i\include -IC:\Users\runneradmin\AppData\Local\pypa\cibuildwheel\Cache\nuget-cpython\python.3.11.9\tools\include -IC:\Users\runneradmin\AppData\Local\pypa\cibuildwheel\Cache\nuget-cpython\python.3.11.9\tools\Include "-IC:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\include" "-IC:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\ATLMFC\include" "-IC:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\VS\include" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\um" "-IC:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\shared" "-IC:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\winrt" "-IC:\Program 
  misc.c

Failed run with v3.3.0 - https://github.com/pythongssapi/python-gssapi/actions/runs/21275788952/job/61235156501?pr=371

We can see that the failing cl.exe command is missing the various Windows Kits\10\include dirs which is where io.h will be defined

"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\bin\HostX86\x64\cl.exe" /c /nologo /O2 /W3 /GL /DNDEBUG /MD -Igssapi/raw -Igssapi\raw -IC:\Users\runneradmin\AppData\Local\Temp\build-env-0k6k8v9b\include -IC:\Users\runneradmin\AppData\Local\pypa\cibuildwheel\Cache\nuget-cpython\python.3.11.9\tools\include -IC:\Users\runneradmin\AppData\Local\pypa\cibuildwheel\Cache\nuget-cpython\python.3.11.9\tools\Include "-IC:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\include" "-IC:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\ATLMFC\include" "-IC:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\VS\include" /Tcgssapi/raw/misc.c /Fobuild\temp.win-amd64-cpython-311\Release\gssapi\raw\misc.obj "-IC:\Program Files\MIT\Kerberos\include" -DMS_WIN64 -DHAS_GSSAPI_EXT_H
  misc.c

  C:\Users\runneradmin\AppData\Local\pypa\cibuildwheel\Cache\nuget-cpython\python.3.11.9\tools\include\pyconfig.h(59): fatal error C1083: Cannot open include file: 'io.h': No such file or directory
  error: command 'C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Tools\\MSVC\\14.44.35207\\bin\\HostX86\\x64\\cl.exe' failed with exit code 2

Weirdly I didn't see this error in a similar library I updated to v3.3.0 which has a similar build process.

I've verified that #2673 fixes the build and #2696 also fixes it. I don't know which direction you want to go with and I don't use uv in my builds but hoping at least one of them is chosen :)

If you're only building 64-bit Windows wheels, I've found that passing --vsenv to meson fixes the issue, like this:

[tool.cibuildwheel.windows]
config-settings = { "setup-args" = "--vsenv" }

I think I understand now why some users are seeing this and others are not. Some users are using ilammy/msvc-dev-cmd to set up their toolchain environment variables. They are hitting this bug due to changes in how we set the PATH variable in 3.3.0. Users that use --vsenv don't see the issue because meson is explicitly finding the VS compiler toolchain.

We'll fix the PATH mangling issue soon.

You can just delete it

      - run: rm 'C:/Program Files/Git/usr/bin/link.EXE' -rf
        if: ${{ runner.os == 'Windows' }}
        shell: bash

I think I understand now why some users are seeing this and others are not. Some users are using ilammy/msvc-dev-cmd to set up their toolchain environment variables. They are hitting this bug due to changes in how we set the PATH variable in 3.3.0.

If it helps, or confuses, I am not explicitly setting up the toolchain in my broken example. Seems like setuptools has the logic to lookup the MSVC paths but something broke the logic with the PATH changes. Very much related to your PATH changes in 3.3.0 but it doesn't seem strictly related to ilammy/msvc-dev-cmd, just the general lookup logic and how setuptools interacts with it.

Fix the PATH mangling in action.yml

Fix the PATH mangling in action.yml (#2723)

Downgrade cibuildwheel to v3.2.1 to fix Windows link.exe issue

Navigation Menu

Repository navigation

meson-python link.exe issue since 3.3.0 release #2663

Description

Build log

CI config

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

meson-python link.exe issue since 3.3.0 release #2663

Description

Description

Build log

CI config

Activity

henryiii commented on Nov 24, 2025

henryiii commented on Nov 24, 2025

jeandet commented on Nov 24, 2025

Starbuck5 commented on Dec 7, 2025

jborean93 commented on Jan 23, 2026

joerick commented on Jan 28, 2026

trim21 commented on Jan 28, 2026

jborean93 commented on Jan 28, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions