Python 3.10.4 restores builds on older Linux systems

A change intended to support newer processors stopped Python from building on an older Linux distribution. Python 3.10.4 repairs that regression. The March 24 release announcement describes a special release prompted by a build failure on Red Hat Enterprise Linux 6, with only ten other fixes beyond 3.10.3. The cause is a mistaken inference about which system headers a successful configuration check establishes.

The original work concerned the alternate signal stack allocated by faulthandler. An extension requesting access to AMX processor state could encounter a kernel refusal because the stack was too small. The March issue discussion follows the repair through its backport and the discovery that it made stable Python releases unbuildable on an older system.

I regard this as part of the cost of Python's extension ecosystem. Libraries need interpreter support for capabilities that ordinary Python code does not expose directly. The interpreter must accommodate those capabilities without making an unrelated build environment fail before an application starts.

Processor state changes the required stack

Oleksandr Pavlyk's report describes an extension requesting permission to use AMX registers. The request failed because CPython's allocated alternate signal stack did not account for the hardware's state requirements. The original allocation used twice SIGSTKSZ, a fixed calculation that could not represent every relevant processor configuration.

The report identifies getauxval(AT_MINSIGSTKSZ) as the Linux interface for obtaining a dynamic minimum signal-stack size. The fix used that information to account for the kernel's requirement. This is a compatibility change between the interpreter and native extensions. The extension's permission request can depend on resources the interpreter allocated earlier for its own error handling.

The discussion also explains the allocation policy. Victor Stinner described reserving SIGSTKSZ for faulthandler itself, with the dynamic amount accounting for the kernel's use. That separates the handler's working space from the state the operating system needs to preserve. The old multiplication supplied a margin, but it could not explicitly express those separate requirements.

Pavlyk noted that the revised calculation could allocate less memory on some machines and more on the processor configuration that motivated the change. A dynamic requirement is useful precisely because a single fixed allocation cannot describe both cases accurately. The intended improvement concerns which information drives the allocation, rather than a universal increase in its size.

A configuration check for the wrong header

The build regression arose because configuration tested for linux/auxvec.h, while the source included sys/auxv.h. Those are different availability questions. The existence of a kernel-related header did not establish the existence of the other header in the build environment.

On March 17, Pablo Galindo reported a fatal compiler error for the missing sys/auxv.h. His comments identify the faulty assumption explicitly. This was not an AMX execution failure on the older machine. Compilation failed because a source file attempted to include a header that was absent.

The distinction matters for portability work. A conditional source path is only as portable as the condition that enables it. Even when the added code handles a newer kernel capability correctly, a broader configuration predicate can expose that code in an environment that cannot compile it. The check and the operation must describe the same dependency.

The 3.10.4 changelog names the repair directly. Python now checks for the existence of sys/auxv.h in faulthandler to avoid compilation failures where that header does not exist. The issue records the corrective changes reaching the maintained branches on March 18. The release carries that narrower feature detection to users.

A build failure can affect package distribution

Galindo also connected the regression to CentOS 6 and its use for building manylinux2010 wheels. That observation broadens the affected audience. A build platform can be older than the systems that eventually install its artifacts, so breaking it can disrupt distribution beyond the owners of that platform.

The issue does not establish that every Python package encountered this failure. It identifies a particular interpreter build failure and explains why a packaging workflow could depend on the affected environment. That is enough to make the regression consequential without assuming an outage across the whole ecosystem.

I dislike the complexity around Python packaging, but this is a concrete reason its compatibility constraints matter. An old build environment can participate in delivering libraries to newer systems. Removing a mistaken header assumption is therefore useful even to someone who has no intention of running an application on that old distribution.

The repair preserves the purpose of the earlier change. Extensions on suitable systems still need an alternate signal stack sized for the relevant kernel and hardware requirements. Systems without the header must remain able to compile Python without selecting the unavailable interface. Python 3.10.4 addresses that separation in its build checks, so supporting a newer processor no longer requires every build environment to supply the same headers.