Skip to content

Bump the ngrok dep and Rust version#163

Merged
bmpngrok merged 2 commits into
mainfrom
bmps/test-against-rust-2024
Jul 2, 2026
Merged

Bump the ngrok dep and Rust version#163
bmpngrok merged 2 commits into
mainfrom
bmps/test-against-rust-2024

Conversation

@bmpngrok

@bmpngrok bmpngrok commented Jun 30, 2026

Copy link
Copy Markdown
Contributor

Verifies ngrok-python builds and passes CI against the new Rust SDK.

Closes AGENT-626

Also refreshes the aws-lc-sys/aws-lc-rs security pins and adjusts the
nix flake's toolchain buildInputs.
@bmpngrok bmpngrok force-pushed the bmps/test-against-rust-2024 branch from 8e23bc0 to bd961b3 Compare July 2, 2026 18:35
@bmpngrok bmpngrok marked this pull request as ready for review July 2, 2026 18:38
@bmpngrok bmpngrok changed the title DO NOT MERGE: CI check against ngrok-rust PR #203 (Rust 2024 + dep bumps) Bump the ngrok dep and Rust version Jul 2, 2026
The `aarch64-unknown-linux-gnu` build job started failing when compiling
`aws-lc-sys` (a transitive C dependency pulled in via rustls -> aws-lc-rs).
The bump in bd961b3 ("bump ngrok to 0.19.0") moved us from
aws-lc-sys 0.28.0 -> 0.41.0 (and aws-lc-rs 1.13.0 -> 1.17.0), and 0.41's
vendored C source is where the trouble starts.

The failure:

    aws-lc/crypto/fipsmodule/cpucap/cpu_aarch64_linux.c:27:36:
      error: 'AT_HWCAP2' undeclared (first use in this function)
         unsigned long hwcap2 = getauxval(AT_HWCAP2);

Root cause: that job cross-compiles inside the
`ghcr.io/rust-cross/manylinux2014-cross:aarch64` image, whose glibc/kernel
headers predate the definition of `AT_HWCAP2`. `AT_HWCAP2` is an ELF
auxiliary-vector key (from <elf.h> / <linux/auxvec.h>). aws-lc-sys 0.41
references it unconditionally in its aarch64 CPU-capability probe, so the C
compile blows up in that old sysroot. This is not related to the Rust 2024
edition work on this branch, and not something aws-lc does wrong -- it's
purely the age of the cross image's headers.

Fix: define the macro explicitly for that one target's C flags.
`AT_HWCAP2` has a fixed, well-known value on Linux (16 = AT_HWCAP,
26 = AT_HWCAP2); it is simply the key passed to getauxval(), so supplying
the canonical 26 is correct rather than a papered-over guess. If a runtime
kernel happens to lack an AT_HWCAP2 auxv entry, getauxval() just returns 0
(no extra CPU features detected) -- there is no miscompile or unsafe path.

We piggyback on the existing target-scoped `CFLAGS_aarch64_unknown_linux_gnu`
export (already present for the ring `-D__ARM_ARCH=8` workaround), which we
confirmed reaches the aws-lc-sys cmake build: the failing cmake invocation
in CI showed `-D__ARM_ARCH=8` already forwarded into CMAKE_C_FLAGS, so
appending `-DAT_HWCAP2=26` lands in the same place.

Scope is deliberately minimal -- only this job is affected:
  * aarch64-unknown-linux-gnu  -- FAILS (old manylinux2014 cross image)  <- fixed here
  * aarch64-unknown-linux-musl -- OK: builds natively on an ubuntu-24.04-arm
    runner against a modern alpine:3.21 image, so its headers define AT_HWCAP2.
  * armv7-unknown-linux-gnueabihf -- OK: 32-bit ARM compiles cpu_arm_linux.c,
    not cpu_aarch64_linux.c, so it never touches this code path.
  * all x86_64 / windows / macos targets -- unaffected.

Alternatives considered and rejected as more disruptive:
  * Switch rustls to the `ring` backend -- would undo the deliberate
    aws-lc-sys/-rs pins cross-ported from the JS SDK (7a67fa9) and affect
    every platform.
  * Downgrade aws-lc-sys -- conflicts with the ngrok 0.19.0 -> aws-lc-rs
    1.17 -> aws-lc-sys 0.41 dependency chain we just adopted.
  * Bump the cross image to manylinux_2_28 -- raises the glibc floor and
    changes the wheel compatibility tag for downstream consumers.
@bmpngrok bmpngrok merged commit 2f006ff into main Jul 2, 2026
16 checks passed
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.

2 participants