uv python install 3.12 is not working on armv7 libc is identify as gnu instead of gnueabihf

[zarch]

I tried uv 0.3.5 to install a specific version of python on my raspberry-pi:

❯ uname -rmo
6.1.21-v7l+ armv7l GNU/Linux

When I try to install python I got:

❯ uv python install 3.12
Searching for Python versions matching: Python 3.12
error: No download found for request: cpython-3.12-linux-armv7-gnu

Looking at the code it seems that all the version available are taken from uv-python/download-metadata.json, where at the moment we have:

{
  "cpython-3.12.5-linux-armv7-gnueabi": {
    "name": "cpython",
    "arch": "armv7",
    "os": "linux",
    "libc": "gnueabi",
    "major": 3,
    "minor": 12,
    "patch": 5,
    "url": "https://github.com/indygreg/python-build-standalone/releases/download/20240814/cpython-3.12.5%2B20240814-armv7-unknown-linux-gnueabi-install_only_stripped.tar.gz",
    "sha256": "7a584de9c2824f43d7a7b1c26eb61a18af770ebd603a74b45d57601ba62ba508"
  },
  "cpython-3.12.5-linux-armv7-gnueabihf": {
    "name": "cpython",
    "arch": "armv7",
    "os": "linux",
    "libc": "gnueabihf",
    "major": 3,
    "minor": 12,
    "patch": 5,
    "url": "https://github.com/indygreg/python-build-standalone/releases/download/20240814/cpython-3.12.5%2B20240814-armv7-unknown-linux-gnueabihf-install_only_stripped.tar.gz",
    "sha256": "a9992b30d7b3ecb558cd12fde919e3e2836f161f8f777afea31140d5fff6362e"
  }
}

Using other tool such as pystand they work as expected:

❯ uvx pystand show
3.9.19 @ 20240814 distribution="armv7-unknown-linux-gnueabihf"
3.10.14 @ 20240814 distribution="armv7-unknown-linux-gnueabihf"
3.11.9 @ 20240814 distribution="armv7-unknown-linux-gnueabihf"
3.12.5 @ 20240814 distribution="armv7-unknown-linux-gnueabihf"

Looking at the code from my understanding uv is trying to infer this information from ldd while pystand look at the platform in a simpler way:

# Default distributions for various platforms
DISTRIBUTIONS = {
    ('Linux', 'x86_64'): 'x86_64-unknown-linux-gnu',
    ('Linux', 'aarch64'): 'aarch64-unknown-linux-gnu',
    ('Linux', 'armv7l'): 'armv7-unknown-linux-gnueabihf',
    ('Linux', 'armv8l'): 'armv7-unknown-linux-gnueabihf',
    ('Darwin', 'x86_64'): 'x86_64-apple-darwin',
    ('Darwin', 'aarch64'): 'aarch64-apple-darwin',
    ('Windows', 'x86_64'): 'x86_64-pc-windows-msvc',
    ('Windows', 'i686'): 'i686-pc-windows-msvc',
}

Perhaps uv should use/integrate a similar approach?

[zarch]

Or at least it would be nice to be able to define / force the right value by command line interface?

[charliermarsh]

@konstin -- Do you know if this is expected to work yet?

[konstin]

iirc we have to detect whether we're on a hardfloat abi or not and use guneabi or gnueabihf depending on that

[zarch]

If you like I can prepare a PR, but I'm not sure which is the best approach to detect if we are are using hardfloat abi or not.

Executing the code enabling the RUST_LOG=trace

❯ RUST_LOG=trace uv python install 3.12 --verbose
DEBUG uv 0.4.2
TRACE Checking lock for `/root/.local/share/uv/python` at `/root/.local/share/uv/python/.lock`
DEBUG Acquired lock for `/root/.local/share/uv/python`
Searching for Python versions matching: Python 3.12
TRACE ld path: /lib/ld-linux-armhf.so.3
TRACE stdout output from `ld`: ""
TRACE stderr output from `ld`: "Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]\nYou have invoked `ld.so', the helper program for shared library executables.\nThis program usually lives in the file `/lib/ld.so', and special directives\nin executable files using ELF shared libraries tell the system's program\nloader to load the helper program from this file.  This helper program loads\nthe shared libraries needed by the program executable, prepares the program\nto run, and runs it.  You may invoke this helper program directly from the\ncommand line to load and run an ELF executable file; this is like executing\nthat file itself, but always uses this helper program from the file you\nspecified, instead of the helper program file specified in the executable\nfile you run.  This is mostly of use for maintainers to test new versions\nof this helper program; chances are you did not intend to run this program.\n\n  --list                list all dependencies and how they are resolved\n  --verify              verify that given object really is a dynamically linked\n\t\t\tobject we can handle\n  --inhibit-cache       Do not use /etc/ld.so.cache\n  --library-path PATH   use given PATH instead of content of the environment\n\t\t\tvariable LD_LIBRARY_PATH\n  --inhibit-rpath LIST  ignore RUNPATH and RPATH information in object names\n\t\t\tin LIST\n  --audit LIST          use objects named in LIST as auditors\n  --preload LIST        preload objects named in LIST\n"
TRACE Tried to find musl version by running `"/lib/ld-linux-armhf.so.3"`, but failed: Could not find musl version in output of: `/lib/ld-linux-armhf.so.3`
DEBUG Released lock at `/root/.local/share/uv/python/.lock`
error: No download found for request: cpython-3.12-linux-armv7-gnu

I see that, in debian, in the ld path it is already indicated the is hardfloat: TRACE ld path: /lib/ld-linux-armhf.so.3, so we could infer from the path, but I'm not sure it is general enough to cover other case and distributions. I tried few other distributions on my laptop:

• fedora (rawhide): TRACE ld path: /lib64/ld-linux-x86-64.so.2
• archlinux (stable): TRACE ld path: /lib64/ld-linux-x86-64.so.2
• alpine(edge): TRACE ld path: /lib/ld-musl-x86-64.so.1

So it seems to me that this pattern is shared among linux distributions.
Perhaps, I can add a if condition within the detect_linux_libc() function that check if the path contains armhf string then it return gnueabihf, if contains just arm then return: gnueabi else continue with the other check.

Otherwise, we can simply implement the same logic used by pystand and see the platform architecture calling uname -m. Other approaches that you would like to follow?

[orgua]

I have the same trouble on a armv7 beaglebone black. Latest uv 0.4.16 won't install any python version, not just 3.12. Would love to be able to use that feature! Armv7 is slow enough and could use every improvement newer py-versions bring :)

[kakkoyun]

I’ve thought through a few different options for detecting whether to use gnueabi or gnueabihf. One possibility is analyzing an ELF binary using readelf (or Goblin) to check for Tag_ABI_VFP_args (see ARM documentation), but I decided to go with a simpler approach: checking /proc/cpuinfo (#7725). The idea is to look for the vfp flag, which indicates hardware floating-point support. There’s some more info on that here.

I have some Raspberry Pis lying around, but they need to be provisioned first. Could I ask for your help testing #7725, @orgua @zarch? I’d be happy to provide a pre-built version of uv from the PR if that’s easier for you!