Skip to content

gh-122931: Allow stable abi3 API extensions to include a multiarch tuple in the filename#152461

Open
stefanor wants to merge 14 commits into
python:mainfrom
stefanor:stable-abi3-multiarch
Open

gh-122931: Allow stable abi3 API extensions to include a multiarch tuple in the filename#152461
stefanor wants to merge 14 commits into
python:mainfrom
stefanor:stable-abi3-multiarch

Conversation

@stefanor

@stefanor stefanor commented Jun 27, 2026

Copy link
Copy Markdown
Contributor

This permits abi3 stable ABI extensions for multiple architectures to be co-installed into the same directory, without clashing with each other, the same way (non-stable ABI) regular extensions can.

It is listed before the current .abi3 suffix because .abi3 extensions are only compatible with future Python releases, not older versions.

This follows on from #122917 which was reduced down to just targetting abi3t

stefanor added 7 commits June 26, 2026 09:12
…ple in the filename

This permits stable ABI extensions for multiple architectures to be
co-installed into the same directory, without clashing with each other,
the same way (non-stable ABI) regular extensions can.

It is listed below the current .abi3 suffix because setuptools will
select the first suffix containing .abi3, as the target filename.
We do this to protect older Python versions predating this patch.
…uple in the filename

This permits `abi3` stable ABI extensions for multiple architectures to be co-installed into the same directory, without clashing with each other, the same way (non-stable ABI) regular extensions can.

It is listed before the current .abi3 suffix because .abi3 extensions are only compatible with future Python releases, not older versions.

This follows on from python#122917 which was reduced down to just targetting `abi3t`
@read-the-docs-community

read-the-docs-community Bot commented Jun 27, 2026

Copy link
Copy Markdown

@brettcannon
brettcannon removed their request for review June 29, 2026 17:53
@encukou

encukou commented Jul 18, 2026

Copy link
Copy Markdown
Member

The SC agreed to add the arch-specific abi3t .so filename. .abi3t.so should always be there.
we should do the same for abi3 as for abi3t. (I talked with the RM and a SC member & they agree; if anyone wants an official clarification from the SC, ask them.)

I'll update & merge this PR.

@encukou encukou added the needs backport to 3.15 pre-release feature fixes, bugs and security fixes label Jul 18, 2026
encukou and others added 2 commits July 18, 2026 17:09
Add ALT_SOABI and SOABI_PLATFORM to test.pythoninfo. Add also
EXTENSION_SUFFIXES of importlib.machinery.
@stefanor

Copy link
Copy Markdown
Contributor Author

This was previously a commit following on from #122917. There has been some movement in there since this was filed. Cherry-picked those commits for here.

@vstinner

Copy link
Copy Markdown
Member

This change adds the following strings to importlib.machinery.EXTENSION_SUFFIXES on a regular build:

  • Emscripten: .abi3-wasm32-emscripten.so and .abi3t-wasm32-emscripten.so
  • macOS: .abi3-darwin.so and .abi3t-darwin.so
  • Ubuntu (x86-64): .abi3-x86_64-linux-gnu.so and .abi3t-x86_64-linux-gnu.so
  • WASI: .abi3-wasm32-wasi.so and .abi3t-wasm32-wasi.so

On Free Threading, it adds the following string to importlib.machinery.EXTENSION_SUFFIXES:

  • macOS: .abi3t-darwin.so
  • Ubuntu (x86-64): .abi3t-x86_64-linux-gnu.so

For example, no new string is added on these platforms:

  • FreeBSD
  • Windows

On the PR gh-122917, @stefanor wrote that the change only impacts Linux. But it does impact other platforms: Emscripten, macOS and WASI for example.

Is it expected/useful to use these new suffixes on Emscripten/WASI? For example, use .abi3-wasm32-emscripten.so suffix instead of .abi3.so.

On macOS, we support Intel and AArch64 architectures but SOABI_PLATFORM is just darwin (without the architecture). Is it expected to omit the architecture from the extension suffix (just darwin in .abi3-darwin.so and .abi3t-darwin.so)? Does it mean that a FAT binary should be produced with multiple architectures?

The cryptography uses the stable ABI. On PyPI, I can only see download files for ARM64 on macOS: https://pypi.org/project/cryptography/#files.

@stefanor

Copy link
Copy Markdown
Contributor Author

This change adds the following strings to importlib.machinery.EXTENSION_SUFFIXES on a regular build:

  • Emscripten: .abi3-wasm32-emscripten.so and .abi3t-wasm32-emscripten.so
  • macOS: .abi3-darwin.so and .abi3t-darwin.so
  • Ubuntu (x86-64): .abi3-x86_64-linux-gnu.so and .abi3t-x86_64-linux-gnu.so
  • WASI: .abi3-wasm32-wasi.so and .abi3t-wasm32-wasi.so

no new string is added on these platforms:

  • FreeBSD
  • Windows

So, I primarily care about Linux here, that's where the pain is. And that's probably the platform where working with multiple architectures is the most common.

To me the addition makes sense and is potentially useful on all of those platforms (FreeBSD and Windows too). But figuring out the details for this all would probably take some time. We could restrict it to Linux only to get this merged now.

Fat binaries are common on macOS, but you'd only build one at a time, and combine them into a fat binary.

@stefanor

Copy link
Copy Markdown
Contributor Author

This change adds the following strings to importlib.machinery.EXTENSION_SUFFIXES on a regular build:

Maybe we're overthinking this. These platforms already have the additional .so extension suffix, we're just doing the same for abi3 and abi3t.

@vstinner

Copy link
Copy Markdown
Member

To me the addition makes sense and is potentially useful on all of those platforms (FreeBSD and Windows too).

Currently, we don't support the "platform triplet" on FreeBSD (same on OpenBSD or NetBSD).

The PLATFORM_TRIPLET variable in configure.ac is set by:

AC_MSG_CHECKING([for the platform triplet based on compiler characteristics])
if $CPP $CPPFLAGS $srcdir/Misc/platform_triplet.c >conftest.out 2>/dev/null; then
  PLATFORM_TRIPLET=`grep '^PLATFORM_TRIPLET=' conftest.out | tr -d '    '`
  PLATFORM_TRIPLET="${PLATFORM_TRIPLET@%:@PLATFORM_TRIPLET=}"
  AC_MSG_RESULT([$PLATFORM_TRIPLET])
else
  AC_MSG_RESULT([none])
fi
rm -f conftest.out

But on FreeBSD, Misc/platform_triplet.c fails to compile:

vstinner@freebsd$ cc -E Misc/platform_triplet.c | grep '^PLATFORM_TRIPLET=' | tr -d ' '
Misc/platform_triplet.c:289:3: error: unknown platform triplet
  289 | # error unknown platform triplet
      |   ^
1 error generated.

Maybe we should explore the ./config.guess option:

vstinner@freebsd$ ./config.guess
x86_64-unknown-freebsd15.0

The commit d3899c1 of issue gh-67169 in 2015 introduced PLATFORM_TRIPLET variable and modified SOABI to use it. The change is part of Python 3.5.

Result of import sysconfig; sysconfig.get_config_var('SOABI'):

  • Python 3.4: 'cpython-34dm'
  • Python 3.5: 'cpython-35dm-x86_64-linux-gnu'

@encukou

encukou commented Jul 19, 2026

Copy link
Copy Markdown
Member

Since the point of the feature is to have different .so names for different platforms, i think:

  • adding -darwin or wasm32-wasi is correct.
  • the fact that nothing is added for FreeBSD is a (low-priority) bug. We can fix it in the future (for cpython-3XX files as well as abi3 ones).
  • Windows uses .pyd instead; changing that would be a different feature.

@encukou encukou added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Jul 19, 2026
@bedevere-bot

Copy link
Copy Markdown

🤖 New build scheduled with the buildbot fleet by @encukou for commit 0ebab06 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F152461%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Jul 19, 2026
@vstinner

Copy link
Copy Markdown
Member

test_curses fails on RHEL8 buildbot workers, but these workers should only be run on Python 3.12 and older. Example: https://github.com/python/buildmaster-config/blob/519dfd6b9757ab889d32677b71c074c5ccc2096c/master/custom/workers.py#L115.

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

Labels

awaiting review needs backport to 3.15 pre-release feature fixes, bugs and security fixes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants