support on manylinux builder image (older glibc)?

[davidszotten]

atm the newest images from https://github.com/pypa/manylinux manylinux_2_28 use glibc 2.28

)$ docker run --rm -ti quay.io/pypa/manylinux_2_28_aarch64:2024-02-16-b3cad8f
[root@378f4d94282b /]# curl -LsSf https://astral.sh/uv/install.sh | sh
System glibc version (`2.28') is too old; using musl
ERROR: there isn't a package for aarch64-unknown-linux-musl-static

[zanieb]

Could you provide some more information?

We explicitly build and test wheels on this image

https://github.com/astral-sh/uv/blob/e923dba4b4a01c70e2a207d5e74aef578cb20887/.github/workflows/build-binaries.yml#L277-L297

[davidszotten]

ah, it looks like i can install with pip but not with your installer script

Could you provide some more information?

sure, what would be helpful?

[MichaReiser]

I think this is the same issue as https://github.com/astral-sh/uv/issues/1392 except that it tries to pick the statically linked musl instead of the dynamic. We're working with axo on a fix. I'll close this issue in favor of https://github.com/astral-sh/uv/issues/1392

[davidszotten]

how come the installer isn't able to use whatever is built for the wheel on the same platform?

[MichaReiser]

We use cargo-dist to generate the installer and the latest version had a bug where it failed to generate the necessary mappings for aarch64-musl.

[davidszotten]

maybe i'm misunderstanding something (my knowledge in this area is limited) so maybe this question makes no sense, but the version installed with pip looks like it is dynamically linked to glibc 2.28

ldd /opt/python/cp312-cp312/bin/uv
	linux-vdso.so.1 (0x0000ffff83094000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000ffff8198b000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000ffff81956000)
	libm.so.6 => /lib64/libm.so.6 (0x0000ffff81895000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000ffff81874000)
	libc.so.6 => /lib64/libc.so.6 (0x0000ffff816fe000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffff83056000)

So my question is: as opposed to (or in addition to) fixing the static musl fallback, could the installer be less strict about it's glibc version requirement System glibc version ('2.28') is too old; using musl ?

[konstin]

I think this is cargo-dist being overly strict, the value looks hardcoded (CC @gankra; For context, you need to use an image such as manylinux_2_28 with glibc 2.28 if you want to build python packages with that compatibility tag, i we unfortunatly should support ancient distros). The other problem is that we need an aarch64-unknown-linux-musl-static package.