0.28 raw-dylib linking regressed MSYS2/MinGW (libpython3X.dll vs python3X.dll)

[ddelange]

Summary

PyO3 0.28 (PR #5866) switched Windows linking to Rust's raw-dylib and hardcoded the imported DLL name as python3X.dll. This regressed MSYS2/MinGW (*-pc-windows-gnu) downstream builds, where the Python DLL is named libpython3X.dll (Unix-style lib prefix). Every Python C-API symbol now comes back undefined at link time.

This was already flagged by @ognevny on the merged PR but doesn't have a tracking issue:
#5866 (comment)

hi, this change seem to regress MINGW downstream builds, probably because we use libpython3.dll library (it uses the lib prefix like any other UNIX environment)

The previous escape hatch (generate-import-lib) is now a deprecated no-op per the 0.28 changelog, so downstreams have no way to opt out aside from pinning pyo3 = "0.27.x".

Downstream impact

• blake3-py 1.0.9 (which bumped to pyo3 0.28): blake3 build is broken on windows (msys2/mingw) oconnor663/blake3-py#109
• borgbackup CI on MSYS2 UCRT64, failing log: https://github.com/borgbackup/borg/actions/runs/27977945398/job/82800454532
• The matching borg build on pyo3 0.27 / blake3-py 1.0.8 succeeds on the same runner: https://github.com/borgbackup/borg/actions/runs/27978763145/job/82803271025

Truncated link error from the failing log:

ld.exe: ...libpyo3-*.rlib: undefined reference to `PyUnicode_FromStringAndSize'
ld.exe: ...libpyo3-*.rlib: undefined reference to `Py_GenericAlias'
ld.exe: ...libpyo3-*.rlib: undefined reference to `PyDict_New'
... (many more)
collect2.exe: error: ld returned 1 exit status

Proposed direction

Emit the lib-prefixed DLL name in extern_python_dll! / the raw-dylib import on *-pc-windows-gnu targets when the Python install is the MSYS2-style one — or expose a build-script knob so downstreams can override the import name.

[chirizxc]

pyo3/pyo3-build-config/src/impl_.rs

Lines 2344 to 2350 in d01e618

	} else if mingw {
	ensure!(
	!abi.kind.is_free_threaded(),
	"MinGW free-threaded builds are not currently tested or supported"
	);
	// https://packages.msys2.org/base/mingw-w64-python
	Ok(format!("python{}.{}", abi.version.major, abi.version.minor))

[messense]

As you have said the fix should be straightforward, feel free to send a PR. But IMO the bigger issue is that we don't have test coverage for MSYS2/MinGW in pyo3 CI except a few cross compilation tests which didn't catch this issue. Thus I would encourage people care about MSYS2/MinGW support to take a bit effort to add CI support here. Thanks!

[ognevny]

I opened #6159 which should append prefix for libnames. I'll test some crates now...

[davidhewitt]

Related, I've asked upstream about supporting arbitrary libpython names under raw-dylib at https://internals.rust-lang.org/t/support-renames-with-link-name-kind-raw-dylib/24415

[ognevny]

#6164 has a workaround which fixes the issue

[ognevny]

Related, I've asked upstream about supporting arbitrary libpython names under raw-dylib at internals.rust-lang.org/t/support-renames-with-link-name-kind-raw-dylib/24415

just to note, library with minor version has the dot separator, while in MSVC there isn't: libpython3.14.dll vs python314.dll, while in other cases appending lib prefix is enough