# Can we consider an unconditional change of \`abi3t.so\` to \`abi3t-SOABI\_PLATFORM.so\` for 3.15 (last-minute) **URL:** \ **Category:** Packaging\ **Tags:** release\ **Created:** [June 26, 2026, 4:25pm UTC](https://discuss.python.org/t/can-we-consider-an-unconditional-change-of-abi3t-so-to-abi3t-soabi-platform-so-for-3-15-last-minute/107919 "2026-06-26T16:25:07Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![stefanor](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stefanor/32/9984_2.png) [@stefanor](https://discuss.python.org/u/stefanor)\ **Post date:** [June 26, 2026, 4:25pm UTC](https://discuss.python.org/t/can-we-consider-an-unconditional-change-of-abi3t-so-to-abi3t-soabi-platform-so-for-3-15-last-minute/107919/1 "2026-06-26T16:25:07Z")
Sorry for spreading this topic all of GitHub and Discourse, but discussion has dragged on for years on [gh-122931: Include multiarch tuple in abi3t filenames by stefanor · Pull Request #122917 · python/cpython · GitHub](https://github.com/python/cpython/pull/122917) and this thread was requested to bring the issue to a wider audience. Are we willing to make a (somewhat) breaking change to 3.15, to avoid needing to support an extra binary extension filename for the long-term future? ## The issue: [PEP-384](https://peps.python.org/pep-384) (stable ABI) was defined before [PEP-3149](https://peps.python.org/pep-3149) (tag extensions to `.so` files) but in practice was only implemented a couple of years after 3149. PEP-3149 anticipated PEP-384, but didn’t provide examples of it. And PEP-3149’s implementation didn’t cover the stable ABI, because it wasn’t something in use yet. [C extension naming doesn't take bitness into account · Issue #67169 · python/cpython · GitHub](https://github.com/python/cpython/issues/67169) lead to cPython including platform tags (the multiarch architecture tuple) in C extension filenames, by default, using the tagging space allowed by PEP-3149. But this was not applied to the stable ABI. I think setuptools only gained support for it in 2016, and it took a few years after that to see wider use. ## What problems does this cause? Debian relies on these tagging mechanisms to allow multiple Python versions, [architectures](https://www.debian.org/doc/debian-policy/ch-controlfields.html#multi-arch), and build types to share the same `dist-packages` library tree. Doing this made supporting newer Python releases in Debian much easier. Multiple Python verision co-installability with the stable ABI is not an issue (by design). Multiple build types were an issue, but we fixed that ([bpo-28401](https://github.com/python/cpython/issues/72587)), and soon the debug build gained the ability to import non-debug-built extensions ([bpo-36722](https://github.com/python/cpython/issues/80903)). Multiple architectures continued to be an issue. This was less immediately obvious, because only packages that opt-into [Multi-Arch co-installability](https://www.debian.org/doc/debian-policy/ch-controlfields.html#multi-arch-same) ran into this problem. Very few Python libraries needed to do this. But over time, as multi-arch use has risen, to currently around 132 multi-arch co-installable Python 3 binary packages, from a total of 1219 architecture-specific Python 3 binary packages. The primary use-case for this is to allow cross-compilation. And in general Debian has been working to improve the number of packages that we can cross-compile. Debian has been carrying a patch since Python 3.13.0, to allow stable ABI extensions to include a platform tag in their filename, allowing this to work. The patch was forwarded (as [#122917](https://github.com/python/cpython/pull/122917)), but then got stuck in review for years, over performance concerns. There was a desire to delay the change until an `abi4` was required. We now have an `abi4` (`abi3t`), but the change didn’t land yet, so we have decisions to make. This issue does not affect other families of Linux distributions (to my knowledge), as none of them handle multiple architectures the same way. Debian’s Multi-Arch is much more powerful than other distributions mechanisms for handling multiple architectures. Of course it affects all Debian derivatives (Ubuntu, etc.). ## The proposed change: Merge [gh-122931: Include multiarch tuple in abi3t filenames by stefanor · Pull Request #122917 · python/cpython · GitHub](https://github.com/python/cpython/pull/122917) in its current form, and backport it to 3.15. This resolves the issue for `abi3t`, supporting only `.abi3t-${SOABI_PLATFORM}.so`, not `.abi3t.so`. Platforms without such a platform tag see no change. [Some build tools](https://github.com/python/cpython/issues/122931#issuecomment-4491021154) already support `abi3t.so` and would need to be updated. I don’t think this is out of the question. I would also like to see some progress on resolving the issue for `abi3.so` [gh-122931: Allow stable abi3 API extensions to include a multiarch tuple in the filename by stefanor · Pull Request #152461 · python/cpython · GitHub](https://github.com/python/cpython/pull/152461), but let’s not boil all the oceans at once… See also: - Tracking issue: [Allow stable ABI extensions to include multiarch tuples in the filename · Issue #122931 · python/cpython · GitHub](https://github.com/python/cpython/issues/122931) - [Update PEP 3149 to explicitly include the stable ABI · Issue #355 · python/steering-council · GitHub](https://github.com/python/steering-council/issues/355) (closed, no update required) - [Update PEP-803 to use multiarch in abi3t · Issue #356 · python/steering-council · GitHub](https://github.com/python/steering-council/issues/356) - [Defining a support policy on overlapping installations](https://discuss.python.org/t/defining-a-support-policy-on-overlapping-installations/105343) (which has had recent discussion on the topic) ---
**Author:** ![stefanor](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stefanor/32/9984_2.png) [@stefanor](https://discuss.python.org/u/stefanor)\ **Post date:** [June 26, 2026, 8:57pm UTC](https://discuss.python.org/t/can-we-consider-an-unconditional-change-of-abi3t-so-to-abi3t-soabi-platform-so-for-3-15-last-minute/107919/2 "2026-06-26T20:57:48Z")
> [@stefanor](#): > > This issue does not affect other families of Linux distributions (to my knowledge), But it is broadly useful for anyone who wants to: - Do embedded (cross-architecture) development in a source tree, having built extensions for multiple architectures sitting next to each other. - Ship a multi-architecture compatible pile of Python, including binary extensions. macOS solves this with fat binaries, but that’s generally not the approach taken in the Linux world. It’s way more convenient when you don’t have to worry about the wrong Python importing the wrong thing. You just point it at a tree, and it works. ---
**Author:** ![hpkfft](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hpkfft/32/34423_2.png) [@hpkfft](https://discuss.python.org/u/hpkfft)\ **Post date:** [June 27, 2026, 5:57pm UTC](https://discuss.python.org/t/can-we-consider-an-unconditional-change-of-abi3t-so-to-abi3t-soabi-platform-so-for-3-15-last-minute/107919/3 "2026-06-27T17:57:25Z")
I like this. For what it’s worth, the first time I built my module with the stable ABI and saw that the result was named `hpk.abi3.so`, I started looking for the bug in my build system that caused the `x86_64-linux-gnu` to be dropped. To quote [The Zen of Python](https://peps.python.org/pep-0020/), > Explicit is better than implicit. ---
**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\ **Post date:** [June 27, 2026, 9:30pm UTC](https://discuss.python.org/t/can-we-consider-an-unconditional-change-of-abi3t-so-to-abi3t-soabi-platform-so-for-3-15-last-minute/107919/4 "2026-06-27T21:30:58Z")
I think it’s fine to change this while we’re in the beta period. I’d be opposed to doing it during the rc period, but doing it now is reasonable IMO. ---
**Author:** ![rgommers](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rgommers/32/837_2.png) [@rgommers](https://discuss.python.org/u/rgommers)\ **Post date:** [June 28, 2026, 10:17am UTC](https://discuss.python.org/t/can-we-consider-an-unconditional-change-of-abi3t-so-to-abi3t-soabi-platform-so-for-3-15-last-minute/107919/5 "2026-06-28T10:17:23Z")
I think it’d also be okay to change in the beta period - some build backends may need to do work and a new release, but that pain is limited and may be worth it, under one condition: this really needs a proper integration test in CPython, not just for extension names but for interleaved multi-architecture builds, with the test checking that if two builds have files with the same name, their content is identical (one job building for Linux x86-64 and aarch64 should be enough). Because this is the second release in a row where this issue has surfaced too late. For 3.14 it was `build-details.json`, now it’s filename extensions. For whatever packaging feature is next, this should be caught before merging the feature, not after support for it has been shipped in build systems and backends. ---
**Author:** ![stefanor](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stefanor/32/9984_2.png) [@stefanor](https://discuss.python.org/u/stefanor)\ **Post date:** [July 1, 2026, 10:23pm UTC](https://discuss.python.org/t/can-we-consider-an-unconditional-change-of-abi3t-so-to-abi3t-soabi-platform-so-for-3-15-last-minute/107919/6 "2026-07-01T22:23:51Z")
> [@rgommers](#): > > this really needs a proper integration test in CPython, not just for extension names but for interleaved multi-architecture builds, with the test checking that if two builds have files with the same name, their content is identical (one job building for Linux x86-64 and aarch64 should be enough). > > > As suggested in \[this thread\](https://discuss.python.org/t/can-we-consider-an-un…coditional-change-of-abi3t-so-to-abi3t-soabi-platform-so-for-3-15-last-minute/107919/5), add some CI tooling to ensure that Python continues to be multi-arch co-installable. > > Explicitly skip checking \`abi3.so\` and \`abi3t.so\` extensions, as they are currently not co-installable (#122931). > > We reuse \`reusable-ubuntu\` to perform an extra set of build+install tests without running the Python test suite. We do not do this testing in the main test suite execution, as achieving multi-arch co-installability requires some non-default configure parameters. But we could share builds, if desired for performance. > > Example failure (without \`abi3\` and \`abi3t\` ignored): https://github.com/stefanor/cpython/actions/runs/28550736484/job/84647793000 > Example success (with them ignored): https://github.com/stefanor/cpython/actions/runs/28551134448/job/84648971317 > > > \* Issue: gh-122931 ---
**Author:** ![ngoldbaum](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ngoldbaum/32/12276_2.png) [@ngoldbaum](https://discuss.python.org/u/ngoldbaum)\ **Post date:** [July 8, 2026, 3:29pm UTC](https://discuss.python.org/t/can-we-consider-an-unconditional-change-of-abi3t-so-to-abi3t-soabi-platform-so-for-3-15-last-minute/107919/7 "2026-07-08T15:29:04Z")
The steering council [weighed in](https://github.com/python/steering-council/issues/356#issuecomment-4870998618) that they’d like `EXTENSION_SUFFIXES` to include both the bare `abit3t`extension and the version with platform tags. Hugo also weighed in as release manager that it’s OK to change this in 3.15. I don’t yet see a specific PR open implementing what Thomas outlined in the steering council issue. @stefanor, were you planing to take care of that before rc1? Does one of your open PRs already implement it? ---
**Author:** ![a-reich](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/a-reich/32/5885_2.png) [@a-reich](https://discuss.python.org/u/a-reich)\ **Post date:** [July 8, 2026, 4:05pm UTC](https://discuss.python.org/t/can-we-consider-an-unconditional-change-of-abi3t-so-to-abi3t-soabi-platform-so-for-3-15-last-minute/107919/8 "2026-07-08T16:05:57Z")
Didn’t the SC’s comment only address adding abi3t files (i.e. only for the brand new ABI)? ---
**Author:** ![ngoldbaum](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ngoldbaum/32/12276_2.png) [@ngoldbaum](https://discuss.python.org/u/ngoldbaum)\ **Post date:** [July 8, 2026, 4:09pm UTC](https://discuss.python.org/t/can-we-consider-an-unconditional-change-of-abi3t-so-to-abi3t-soabi-platform-so-for-3-15-last-minute/107919/9 "2026-07-08T16:09:20Z")
You’re right, their response only referred to abi3t. ---
**Author:** ![stefanor](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stefanor/32/9984_2.png) [@stefanor](https://discuss.python.org/u/stefanor)\ **Post date:** [July 18, 2026, 2:44pm UTC](https://discuss.python.org/t/can-we-consider-an-unconditional-change-of-abi3t-so-to-abi3t-soabi-platform-so-for-3-15-last-minute/107919/10 "2026-07-18T14:44:01Z")
> [@ngoldbaum](#): > > I don’t yet see a specific PR open implementing what Thomas outlined in the steering council issue. @stefanor, were you planing to take care of that before rc1? Does one of your open PRs already implement it? Updated [GH-122917](https://github.com/python/cpython/pull/122917) to include both variants of `.abi3t.so` (and not `.abi3-TAG.so`)