Add target armv6-unknown-linux-*eabihf

[MichaIng]

This would add full support for the early Raspberry Pi models: Raspberry Pi 1 and Zero, which are still widely in use. uv itself does have the arm-unknown-linux-musleabihf builds for this architecture already, but Python cannot be installed. Those slow RPi models would benefit particularly from pre-compiled Python builds.

Not sure about gnueabihf vs musleabihf, I guess best is to keep it in sync with uv and use musleabihf. IIRC uv is first looking for a Python build that matches its own triple.

However, the big problem is probably that there are no "official" maintained Raspbian base Docker images. There are some very old ones, though: https://hub.docker.com/u/raspbian
The best main ones are from tianon: https://hub.docker.com/r/tianon/raspbian
But all no verified publishers.
Balena stopped maintaining theirs: https://hub.docker.com/r/balenalib/rpi-raspbian

[zanieb]

We looked into this briefly and I think we'd need a different build toolchain so it's probably out of scope.

[MichaIng]

At least Debian does not have the cross-compiling toolchain. Easiest would be Raspbian base image run with QEMU.

An alternative would be armel, but it is softfloat and performs worse on those RPi models.

[jjhelmus]

The armv7-unknown-linux-gnueabi target uses the Debian toolchain for thearmel port. It should work on armv5 and above but uses the EABI that does not use the VFP for passing function arguments (the armhf port does). From my limited testing this does not work os Raspberry Pi OS as the loader and libc use the VFP based EABI.

I also tried to build an armv6 compatible distribution with the Debian armhf toolchain, but it links agains the system gcc/libc runtime which results in a armv7 requirement.

[MichaIng]

The armv7-unknown-linux-gnueabi target uses the Debian toolchain for thearmel port. It should work on armv5

Interesting, but why is it called armv7 then? Does it not use ARMv7-only instructions like NEON? If not, wouldn't it make sense to name it arm-unknown-linux-gnueabi, so armv6l hosts can match and use it?

I will try to force uv downloading this on an RPi Zero W, for testing.

From my limited testing this does not work os Raspberry Pi OS as the loader and libc use the VFP based EABI.

You mean Raspbian cannot build armel? Yes, it is armhf without NEON, essentially.

I also tried to build an armv6 compatible distribution with the Debian armhf toolchain, but it links agains the system gcc/libc runtime which results in a armv7 requirement.

Yes exactly => NEON, which cannot work on armv6l.

---

Debian's armel can run on armv6l, but since it is essentially ARMv5, and without VFP, it does not perform that well. Earliest Raspberry Pi images were Debian armel, before Raspbian was created, to bring VFP without NEON (and other ARMv7-only instructions) to the Raspberry Pi.

Since implementing actual armv6hf seems difficult, requires a custom toolchain or Raspbian base image, allowing armv6l to download the armel Python build, or add an explicit armel build, sounds like the better option. I'll test it.

[jjhelmus]

You mean Raspbian cannot build armel? Yes, it is armhf without NEON, essentially.

From the Debian ARM Hard Float ports page:

The Arm EABI specification covers calling conventions across libraries and binaries. It defines two incompatible ABIs: one uses (VFP) floating point registers for passing function arguments, the other does not.

Raspbian/Raspberry Pi uses the EABI that passes arguments via VFP. The armv7-unknown-linux-gnueabi distribution uses the other EABI (e.g. EABI that armel uses).

Here is what I get when I try to run the a recent distribution on an RPI 1 with RaspberryPi OS:

$ tar xf cpython-3.14.3+20260310-armv7-unknown-linux-gnueabi-install_only_stripped.tar.gz
$ ./python/bin/python3.14
-bash: ./python/bin/python3.14: cannot execute: required file not found
$ readelf -l ./python/bin/python3.14 | grep interpr
      [Requesting program interpreter: /lib/ld-linux.so.3]
$ ls /lib/ld*
/lib/ld-linux-armhf.so.3
$ sudo ln -s /lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3
 $ ./python/bin/python3.14
Floating point exception

[jjhelmus]

Interesting, but why is it called armv7 then? Does it not use ARMv7-only instructions like NEON? If not, wouldn't it make sense to name it arm-unknown-linux-gnueabi, so armv6l hosts can match and use it?

There is no deep reason for the armv7 name, the target was added in #235 without discussion on the name. arm or armv5 would be a better name IMHO but I'm not sure how changing the name now would effect uv matching.

The actual binary targets ARMv5T:

❯ curl -SLO https://github.com/astral-sh/python-build-standalone/releases/download/20260320/cpython-3.14.3+20260320-armv7-unknown-linux-gnueabi-install_only_stripped.tar.gz
❯ tar xf cpython-3.14.3+20260320-armv7-unknown-linux-gnueabi-install_only_stripped.tar.gz
❯ readelf -A python/bin/python
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "5T"
  Tag_CPU_arch: v5T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int

[MichaIng]

Ah, so the armel build dynamically links armel libc. Okay then it cannot work on Raspbian/Raspberry Pi OS (32-bit), indeed.

So it would either require some 3rd party cross-compile armv6hf toolchain, or a 3rd party Raspbian base image run on GitHub ARM runners or with QEMU. Quite a PITA this architecture 😅.

[jjhelmus]

So it would either require some 3rd party cross-compile armv6hf toolchain, or a 3rd party Raspbian base image run on GitHub ARM runners or with QEMU. Quite a PITA this architecture 😅.

Exactly. The first Raspberry Pi is unfortunately in that middle ground between armel and armhf.

[jjhelmus]

For reference the armv7-unknown-linux-gnueabi distributions do work on armel Debian distributions running on a RPi 1:

$ curl -SLO https://github.com/astral-sh/python-build-standalone/releases/download/20260320/cpython-3.14.3+20260320-armv7-unknown-linux-gnueabi-install_only_stripped.tar.gz
...
$ tar xf cpython-3.14.3+20260320-armv7-unknown-linux-gnueabi-install_only_stripped.tar.gz
$ ./python/bin/python3.14 -m platform
Linux-6.1.0-13-rpi-armv6l-with-glibc2.36

Unfortunately uv does match this distribution when requested.

[MichaIng]

Right, some language toolchains like Rust and Go support it quite well for cross-compiling, but when it comes to C/C++ and others ...

So I see: currently you use Debian Docker base images, either natively compiling x86_64 and aarch64, or cross-compiling with Debian's C/C++/libc packages, dynamically linking the respective libc in the Python build. That way, Raspbian armv6hf builds are not possible, but would require a special-handling, implementing a 3rd party armv6hf toolchain, or using a 3rd party Raspbian base image. Sadly, this seems out of scope/too much work for an architecture just one guy is asking for 😅.

I would offer to try implementing this entirely, running a Raspbian base image on the GitHub ARM runner. But that there is no official/verified publisher for those images remains an issue. And it would need some adjustments among the runner/host/target matching to accept armv6 as "native" build for the aarch64 runner, as it would otherwise by default be done on a x86_64 runner, if I saw the logic correctly. EDIT: Ah wait, the ubuntu-24.04-arm runner is not used currently, so that could be added to the list with armv6l architecture.