On 06/01/2026 15:45, Christoph Reiter via Cygwin-apps wrote:
On Tue, Jan 6, 2026 at 4:19 PM Marco Atzeri
<[email protected]> wrote:
On 06/01/2026 15:21, Christoph Reiter wrote:
On Tue, Jan 6, 2026 at 2:03 PM Marco Atzeri <[email protected]> wrote:
Anything else I should add to a respin of 3.12.12 and 3.9.16 ?
You could add stable ABI/limited API/abi3 support
https://github.com/msys2/MSYS2-packages/blob/b2b1757ab8752919afea4d0a7c1367dd77729292/python/991-py-limited-api.patch
(and replace msys-python3.dll with libpython3.dll in there)
Note that that contains a symbol list generated for 3.12 and I don't
know if that works for older Python versions. And with the DLL not
being versioned, only one package can provide it.
To regenerate the list you'd need to `python
./Tools/build/stable_abi.py --generate --cyg-python3dll
PC/cyg-python3dll.c Misc/stable_abi.toml` with that patch applied.
This does not seem a good idea. I do not have the bandwith to update all
packages at the same time so multiple version will be always
present.
Yeah, hm, I'm not sure how to handle that best in a distro with
multiple parallel versions. On Linux it's easy because there are no
file name conflicts and no explicit linking in extensions.
I don't quite understand the use case for extensions linked against the
"limited API"
In our packaging pipeline, because the binary wheel only exists
transiently before we turn it into an installed package for a specific
python version, there doesn't seem any advantage to that.
(and indeed, as you point out, because the shared library name is fully
resolved for PE, it's actually still linked against the runtime for a
specific python version...)
