Build CPython against modern kernel UAPI headers on *-linux-gnu targets#1163
Build CPython against modern kernel UAPI headers on *-linux-gnu targets#1163jjhelmus wants to merge 4 commits into
Conversation
Package Debian's linux-libc-dev headers as a build dependency for *-linux-gnu targets. This new linux-uapi package provides userspace header from a modern Linux kernel (currently 7.0.12). When building CPython on *-linux-gnu targets use these headers to enable modern kernel features, such as os.pidfp_open. At runtime if the kernel does not support the needed syscalls ENOSYS will be returned.
Verify that no sysconfig variables contains the build-only linux-uapi path.
Verify that building against the modern Linux UAPI headers enables os.pidfd_open on GNU/Linux targets.
jjhelmus
added
platform:darwin
|
The include guard in posixmodule.py for sys/syscall.h is |
|
Oh, this is an interesting approach. I think it seems reasonable and safe! Note that the quirk is technically already true of "normal" Python distributions if you run a newer OS image in e.g. a Docker container on a host with an older kernel. So generic code (libraries, etc.) already need to both test |
3 participants
Use modern Linux kernel UAPI headers when building CPython for glibc Linux targets.
Adds a
linux-uapipackage to the project that contains the unpackedlinux-libc-devpackage from a modern Debian release, currentlytrixie-backports. This provides Linux UAPI headers from a modern kernel release.Building CPython against these headers makes newer syscall definitions and macros available at build time, enabling CPython functionality such as
os.pidfd_open.This does not increase the minimum required glibc or runtime kernel version.
APIs compiled using these definitions may still fail at runtime. For example, if an API uses a direct syscall and the running kernel does not implement it, the kernel returns
ENOSYS, which Python exposes as anOSError.Consequently, functions such as
os.pidfd_openwill exist when running on an older kernel that does not implement the corresponding syscall. Applications should handleOSErrorwitherrno.ENOSYSwhen runtime kernel support is uncertain.This should be included as a quirk of
python-build-standaloneand documented as such. The trade-off here is worth introducing this quirk.Related to #193
Related to astral-sh/uv#11811, astral-sh/uv#9374