8000 Fix Windows free-threaded builds on Python3.14 by ngoldbaum · Pull Request #2632 · PyO3/maturin · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Fix Windows free-threaded builds on Python3.14 #2632

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Jun 6, 2025
Merged

Fix Windows free-threaded builds on Python3.14 #2632

merged 2 commits into from
Jun 6, 2025

Conversation

ngoldbaum
Copy link
Contributor
@ngoldbaum ngoldbaum commented Jun 4, 2025 •
edited
Loading

Fixes #2630

I see you're not running CI testing against 3.14 - is there any appetite for setting that up?

Also for reasons I don't understand, I never saw the error about Python not bundling abiflags in sysconfig on windows. The error generated by bail seems to get swallowed somehow.

@messense
Copy link
Member
messense commented Jun 5, 2025

Happy to accept a PR to add 3.14 and 3.14t in CI now that it has beta releases.

@messense
Copy link
Member
messense commented Jun 5, 2025

"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.43.34808\bin\HostARM64\ARM64\link.exe" /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:src/c/libffi_arm64 /LIBPATH:C:\a\maturin\maturin\test-crates\venvs\develop-cffi-mixed-cpython\libs /LIBPATH:C:\hostedtoolcache\windows\Python\3.13.4\arm64\libs /LIBPATH:C:\hostedtoolcache\windows\Python\3.13.4\arm64 /LIBPATH:C:\a\maturin\maturin\test-crates\venvs\develop-cffi-mixed-cpython\PCbuild\arm64 "/LIBPATH:C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.43.34808\ATLMFC\lib\ARM64" "/LIBPATH:C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.43.34808\lib\ARM64" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.26100.0\ucrt\arm64" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.26100.0\um\arm64" ffi.lib /EXPORT:PyInit__cffi_backend build\temp.win-arm64-cpython-313\Release\src\c_cffi_backend.obj /OUT:build\lib.win-arm64-cpython-313_cffi_backend.cp313-win_arm64.pyd /IMPLIB:build\temp.win-arm64-cpython-313\Release\src\c_cffi_backend.cp313-win_arm64.lib
LINK : fatal error LNK1104: cannot open file 'python313t.lib'

Looks like somehow pip install cffi identified 3.13 as 3.13t on arm64 Windows?

@ngoldbaum
Copy link
Contributor Author
ngoldbaum commented Jun 5, 2025 •
edited
Loading

Looks like somehow pip install cffi identified 3.13 as 3.13t on arm64 Windows?

Very weird. Did this happen on a CI environment somewhere?

I also want to figure out what is swallowing the errors returned by fun_with_abi_flags. It wasn't particularly fun to bisect with print debugging to figure out where the early return was happening.

8000
@ngoldbaum
Copy link
Contributor Author

Oh wait, I see, it happened here...

@ngoldbaum
Copy link
Contributor Author

I also want to figure out what is swallowing the errors returned by fun_with_abi_flags. It wasn't particularly fun to bisect with print debugging to figure out where the early return was happening.

This is happening because of the match statement here:

maturin/src/build_options.rs

Lines 1271 to 1276 in 87c04b7

for interp in interpreter {
match PythonInterpreter::check_executable(interp.clone(), target, bridge) {
Ok(Some(interp)) => found_interpreters.push(interp),
_ => missing.push(interp.clone()),
}
}

Maybe we shouldn't always try to fall back to sysconfig if an error happens there?

@ngoldbaum
Copy link
Contributor Author
ngoldbaum commented Jun 5, 2025 •
edited
Loading

I guess I can add debug logging at least without changing behavior.

Edit: ended up refactoring to not unpack a Result<Option> directly. Let me know if discarding errors there is done on purpose and we need to do something more fine-grained.

@ngoldbaum
Copy link
Contributor Author
ngoldbaum commented Jun 5, 2025 •
edited
Loading

The failures might be because of https://discuss.python.org/t/heads-up-3-13-5-release-coming-soon/94535

@ngoldbaum
Copy link
Contributor Author

Yeah, here it is failing on current main in a run on my fork: https://github.com/ngoldbaum/maturin/actions/runs/15472452714/job/43560045782

@messense messense merged commit da2b3c9 into PyO3:main Jun 6, 2025
41 of 42 checks passed
@messense
Copy link
Member
messense commented Jun 6, 2025

Thanks!

@ngoldbaum
Copy link
Contributor Author

Awesome, thanks for merging. If you can cut a release too that would unblock me working on 3.14 support elsewhere.

@BrewTestBot BrewTestBot mentioned this pull request Jun 9, 2025
Merged
@messense
Copy link
Member
messense commented Jun 9, 2025

Released in v1.8.7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@messense messense messense approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Windows python3.14t builds fail with linking error
2 participants
@ngoldbaum @messense
0