Repository navigation
copy_file_range is missing on GNU builds #776
Description
aarch64-unknown-linux-gnu / 3.12 / pgo+lto: missing https://github.com/astral-sh/python-build-standalone/actions/runs/17052876533/job/48344644002#step:8:17198
ppc64le-unknown-linux-gnu / 3.12 / noopt: missing https://github.com/astral-sh/python-build-standalone/actions/runs/17052876533/job/48344644141#step:8:19234
x86_64_v3-unknown-linux-gnu / 3.13 / freethreaded+pgo+lto: missing https://github.com/astral-sh/python-build-standalone/actions/runs/17052876533/job/48344644346#step:8:19236
x86_64_v4-unknown-linux-musl / 3.14 / debug+static: present https://github.com/astral-sh/python-build-standalone/actions/runs/17052876533/job/48344643687#step:8:5017
$ uname -mpio
aarch64 aarch64 aarch64 GNU/Linux
$ mise install
mise hint installing precompiled python from astral-sh/python-build-standalone
$ ~/.local/share/mise/installs/python/3.12.11/bin/python -VV
Python 3.12.11 (main, Aug 18 2025, 19:20:54) [Clang 20.1.4 ]
$ ~/.local/share/mise/installs/python/3.12.11/bin/python -c 'import os; os.copy_file_range'
Traceback (most recent call last):
File "<string>", line 1, in <module>
AttributeError: module 'os' has no attribute 'copy_file_range'
Activity
zanieb commentedon Aug 27, 2025
Is this just the same as #193?
raylu commentedon Aug 27, 2025
ah, yes it is!
although I'm confused why/how the musl versions support it then
geofft commentedon Aug 28, 2025
We seem to target a newer baseline OS for the musl builds - for glibc we try to be compatible with OSes from around ~2014 (for most architectures we build on Debian 8/glibc 2.17), but for the dynamic musl builds we are targeting ~2022 (we build on Ubuntu 22.04/musl 1.2.2). I think it's just that nobody has asked for older musl builds, since the target audience is usually users of the
alpine:latestDocker image. And the static musl builds don't need to be compatible with any version already installed on the system, so we use the latest available version (1.2.5) for them.zanieb commentedon Aug 28, 2025
That's correct, e.g., see #541 (comment)
os.pidfd_open()#193