`fixup_for_abi3_version` downgrades version causing wrong link library name when cross-compiling for Android

[messense]

Bug Description

When cross-compiling an abi3 extension module for Android with PYO3_CROSS_LIB_DIR pointing to a Python 3.14 installation (via build-details.json), the linker fails with:

ld.lld: error: unable to find library -lpython3.7m

The target has Python 3.14, but pyo3 generates -lpython3.7m instead.

See the full CI log: https://github.com/PyO3/maturin-action/actions/runs/24198305015/job/70634639917

Root Cause

In from_pyo3_config_file_env(), after reading the config file (which has version=3.14, abi3=false), the following happens:

1. config.abi3 |= is_abi3() → sets abi3 = true (from Cargo feature)
2. config.fixup_for_abi3_version(get_abi3_version()) → unconditionally sets self.version = 3.7 (from abi3-py37 minimum)
3. apply_default_lib_name_to_config_file() → computes lib_name from the now-downgraded version 3.7
4. default_lib_name_unix() for version 3.7 returns "python3.7m" (the m abiflag workaround for <= 3.7)
5. Since is_linking_libpython_for_target() returns true for Android, this incorrect library name is emitted as -lpython3.7m

The fundamental problem is that fixup_for_abi3_version downgrades version to the abi3 minimum, but version is then also used to derive the link library name. The abi3 minimum version is relevant for the Python C API compatibility level, but the link library should match the actual target Python installation, not the abi3 minimum.

Steps to Reproduce

1. Set up cross-compilation for aarch64-linux-android
2. Download the Android Python 3.14 standalone build
3. Set PYO3_CROSS_LIB_DIR to the Python prefix/lib directory (containing build-details.json)
4. Build an abi3 pyo3 crate (e.g., with abi3-py37 feature)

The build will fail with unable to find library -lpython3.7m.

Environment

• pyo3 v0.28.2
• Target: aarch64-linux-android
• Python: 3.14.3 (standalone Android build from python.org)
• maturin sets PYO3_CONFIG_FILE with version=3.14, abi3=false, lib_dir=<PYO3_CROSS_LIB_DIR>

[davidhewitt]

Does the android Python distribution have libpython3.so, i.e. a proper "abi3" lib? If the build is going to knowingly link against a version-specific lib, it seems like a waste to de-optimize the build to only use the limited API functionality.

Some other thoughts:

• This seems somewhat related to try to link non abi3 lib python3x.lib when abi3 enabled #5148 which we fixed by moving apply_default_lib_name_to_config_file after abi3 detection (i.e. probably directly causing the problem present here).
• I have previously wondered about the fact that the "target ABI" (which I guess includes the abi3 version) is a separate detail to the interpreter version. cc @ngoldbaum has overlap with what I was saying in add PythonABI and new builder structs for pyo3-build-config InterpreterConfig #5924

[messense]

It seems to have both libpython3.so and libpython3.X.so (https://www.python.org/ftp/python/3.14.3/python-3.14.3-aarch64-linux-android.tar.gz)

$ ls /tmp/android-python/prefix/lib/
engines-3            libcrypto.so         libpython3.so        libsqlite3.so        libssl_python.so     ossl-modules         python3.14
libcrypto_python.so  libpython3.14.so     libsqlite3_python.so libsqlite3.so.0      libssl.so            pkgconfig

[davidhewitt]

I commented in #5924 (comment) with a solution which I think cleans up the issue with fixup_for_abi3_version.

For the specific android problem encountered here, it seems to me that it would be correct to add logic to link using libpython3.so for android when using abi3, as it seems to be present, unlike other linux platforms.

[messense]

I'm not totally sure about abi3 support for Android, at least PEP 738 says:

All Python extension modules must therefore be explicitly linked against libpython3.x.so when building for Android.

[ngoldbaum]

I commented in #5924 (comment) with a solution which I think cleans up the issue with fixup_for_abi3_version.

I'll try to update #5924 this week to take this into account.

[davidhewitt]

I also asked in CPython about the android case at python/cpython#148544