Skip to content

Define AT_HWCAP* when <sys/auxv.h> hides them - #3429

Open
Xeonacid wants to merge 2 commits into
aws:mainfrom
Xeonacid:fix/ppc64le-at-hwcap2-xopen-source
Open

Define AT_HWCAP* when <sys/auxv.h> hides them#3429
Xeonacid wants to merge 2 commits into
aws:mainfrom
Xeonacid:fix/ppc64le-at-hwcap2-xopen-source

Conversation

@Xeonacid

@Xeonacid Xeonacid commented Aug 17, 2026

Copy link
Copy Markdown

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 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 (#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

Description of changes:

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.

Call-outs:

None

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
Xeonacid requested a review from a team as a code owner August 17, 2026 02:09
@justsmth
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>
@justsmth
justsmth force-pushed the fix/ppc64le-at-hwcap2-xopen-source branch from 345afe4 to aca2c54 Compare August 19, 2026 16:42

@justsmth justsmth left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! The change looks good, but I pushed another commit to update the comments to better align with what I found when researching this.

@justsmth
justsmth temporarily deployed to manual-approval August 19, 2026 16:45 — with GitHub Actions Inactive
@github-actions

Copy link
Copy Markdown
Contributor

🔒 Security ReviewView Report

Please review before merging.

@codecov-commenter

codecov-commenter commented Aug 24, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.06%. Comparing base (18c226e) to head (d260c5c).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3429      +/-   ##
==========================================
- Coverage   78.06%   78.06%   -0.01%     
==========================================
  Files         700      700              
  Lines      124704   124704              
  Branches    17325    17325              
==========================================
- Hits        97349    97344       -5     
- Misses      26488    26494       +6     
+ Partials      867      866       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

prasden added a commit that referenced this pull request Aug 25, 2026
### Context and motivation

- Addendum to #3445

- Looking at #3429 from an external
contributor, there still remains "deployment" noise as `android-omnibus`
runs its `device-farm` job as a 6-way build matrix, and each matrix job
references an `environment` directly.
- [GitHub creates a deployment
record](https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments#how-environments-relate-to-deployments)
per job that references an environment, so those six jobs produce six
deployment entries that show up on the timeline UI. This gets noisy on
PRs from external contributors.

### Description of changes

This PR moves the `environment` reference outside of the matrix and into
a new `maintainer-approval` job that `device-farm` now depends on via
`needs`. The environment is declared once, so `android-omnibus` will
produce one deployment instead of six. `device-farm` still waits on
maintainer approval, so external PRs still pause for maintainer approval
before the build runs.

On external contributor PRs, this will cut down the deployments on PRs
from 7 to 2 ( previously 6 for android + 1 for security review -> now 1
for `android-omnibus` + 1 for `security-review`) for each commit.

External contributors will still need approval for any workflows to run
on their PRs , and maintainers will not have any deployments as added in
#3445.

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 and others added 2 commits August 31, 2026 08:39
### 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.
glibc AT_* constants come from <elf.h>, which is not gated on feature-test macros: -D_XOPEN_SOURCE=700 without _GNU_SOURCE does not hide AT_HWCAP2 (verified on glibc 2.17/el7 and glibc 2.39). The actual trigger is sysroots built from vanilla glibc <= 2.17, which predate AT_HWCAP2 (added in glibc 2.18). CentOS 7 glibc 2.17 carries a backport, so stock manylinux2014 images are unaffected.

Also replace a stray em dash with "--" in a nearby comment.
@justsmth
justsmth force-pushed the fix/ppc64le-at-hwcap2-xopen-source branch from 8bc0f9d to d260c5c Compare August 31, 2026 12:39
@justsmth
justsmth requested a review from geedo0 August 31, 2026 12:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants