Define AT_HWCAP* when <sys/auxv.h> hides them - #3429
Open
Xeonacid wants to merge 1 commit into
Open
Conversation
### Issues: Regressed by aws#3250. Observed downstream when aws-lc-sys 0.44 built AWS-LC on manylinux 2.17 for powerpc64le: https://github.com/astral-sh/uv/actions/runs/31985144822/job/95258879338 ### Description of changes: aws#3250 removed the `#if defined(AT_HWCAP2)` guard from `cpu_ppc64le.c` because the new helper header defines `AT_HWCAP2` on the `/proc/self/auxv` fallback path, and assumed `<sys/auxv.h>` always defines it otherwise. That assumption is false: glibc only advertised `AT_HWCAP2` starting in 2.18 (aws#1682), and even later headers can hide it under `-D_XOPEN_SOURCE=700` without `_GNU_SOURCE`. aws-lc-sys Linux builds use exactly those flags, so `cpu_ppc64le.c` fails to compile on manylinux 2.17: cpu_ppc64le.c:69:38: error: 'AT_HWCAP2' undeclared Provide the Linux UAPI values (`include/uapi/linux/auxvec.h`) whenever the system header omits them, for both the libc `getauxval` path and the `/proc/self/auxv` fallback. ### Testing: * `gcc -std=c99 -D_XOPEN_SOURCE=700` compiles a TU that includes `cpu_getauxval_linux.h` and calls `getauxval(AT_HWCAP2)`. * Same compile with `-DOPENSSL_GETAUXVAL_FORCE_PROC_FALLBACK`. By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.
Xeonacid
requested a deployment
to
manual-approval
August 17, 2026 02:10 — with 
GitHub Actions
Waiting
GitHub Actions
Waiting
Xeonacid
requested a deployment
to
manual-approval
August 17, 2026 02:10 — with
GitHub Actions
Waiting
GitHub Actions
Waiting
Xeonacid
requested a deployment
to
manual-approval
August 17, 2026 02:10 — with
GitHub Actions
Waiting
GitHub Actions
Waiting
Xeonacid
requested a deployment
to
manual-approval
August 17, 2026 02:10 — with
GitHub Actions
Waiting
GitHub Actions
Waiting
Xeonacid
requested a deployment
to
manual-approval
August 17, 2026 02:10 — with
GitHub Actions
Waiting
GitHub Actions
Waiting
Xeonacid
requested a deployment
to
manual-approval
August 17, 2026 02:10 — with
GitHub Actions
Waiting
GitHub Actions
Waiting
Xeonacid
requested a deployment
to
manual-approval
August 17, 2026 02:10 — with
GitHub Actions
Waiting
GitHub Actions
Waiting
justsmth
self-requested a review
August 18, 2026 17:31
zanieb
added a commit
to astral-sh/uv
that referenced
this pull request
Aug 18, 2026
<!-- Thank you for contributing to uv! To help us out with reviewing, please consider the following: - Does this pull request include a summary of the change? (See below.) - Does this pull request include a descriptive title? - Does this pull request include references to any relevant issues? --> ## Summary <!-- What's the purpose of the change? What does it do, and why? --> The statically linked `riscv64gc-unknown-linux-musl` release binary segfaulted during HTTPS. Fat LTO plus the musl-cross GCC 12.4 toolchain miscompiled `aws-lc-sys` 0.39, and rustls then dereferenced a null connection. `aws-lc-rs` 1.18.0 (`aws-lc-sys` 0.44.0) no longer crashes under that same release profile. I investigated but failed to find the exact reason for this. But simply bumping the version works on my end. Also fix a build failure for ppc64 after bumping. See aws/aws-lc#3429 Fixes #21151 ## Test Plan <!-- How was it tested? --> Build locally the same way as the CI does, run `uvx -vv nox --version` on riscv64, and it no longer crashes. --------- Co-authored-by: Zanie Blue <contact@zanie.dev>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issues:
Regressed by #3250. Observed downstream when aws-lc-sys 0.44 built AWS-LC on manylinux 2.17 for powerpc64le:
https://github.com/astral-sh/uv/actions/runs/31985144822/job/95258879338
#3250 removed the
#if defined(AT_HWCAP2)guard fromcpu_ppc64le.cbecause the new helper header definesAT_HWCAP2on the/proc/self/auxvfallback path, and assumed<sys/auxv.h>always defines it otherwise.That assumption is false: glibc only advertised
AT_HWCAP2starting in 2.18 (#1682), and even later headers can hide it under-D_XOPEN_SOURCE=700without_GNU_SOURCE. aws-lc-sys Linux builds use exactly those flags, socpu_ppc64le.cfails to compile on manylinux 2.17:Description of changes:
Provide the Linux UAPI values (
include/uapi/linux/auxvec.h) whenever the system header omits them, for both the libcgetauxvalpath and the/proc/self/auxvfallback.Call-outs:
None
Testing:
gcc -std=c99 -D_XOPEN_SOURCE=700compiles a TU that includescpu_getauxval_linux.hand callsgetauxval(AT_HWCAP2).-DOPENSSL_GETAUXVAL_FORCE_PROC_FALLBACK.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.