uclibc: cannot find value `AT_MINSIGSTKSZ`

[xtqqczze]

   Compiling std v0.0.0 (~/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/library/std)
error[E0425]: cannot find value `AT_MINSIGSTKSZ` in crate `libc`
   --> ~/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/library/std/src/sys/pal/unix/stack_overflow.rs:310:63
    |
310 | ...fe { libc::getauxval(libc::AT_MINSIGSTKSZ) };
    |                               ^^^^^^^^^^^^^^
    |
   ::: ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/libc-0.2.183/src/unix/linux_like/linux/uclibc/mod.rs:400:1
    |
400 | pub const MINSIGSTKSZ: c_int = 2048;
    | ---------------------------- similarly named constant `MINSIGSTKSZ` defined here
    |
help: a constant with a similar name exists
    |
310 -         let dynamic_sigstksz = unsafe { libc::getauxval(libc::AT_MINSIGSTKSZ) };
310 +         let dynamic_sigstksz = unsafe { libc::getauxval(libc::MINSIGSTKSZ) };
    |

For more information about this error, try `rustc --explain E0425`.
error: could not compile `std` (lib) due to 1 previous error

[xtqqczze]

This is a regression in the libc crate, introduced sometime between 0.2.178 and 0.2.180 . You should open a ticket there. CC @skrap as target maintainer for this platform.

Originally posted by @asomers in #154679

[tgross35]

This was a correction, there is no AT_MINSIGSTKSZ defined in uclibc. There is discussion at #4479.

[skrap]

That constant is kernel API, so ideally we'd share a definition somewhere in the linux level of the libc crate, rather than letting each of gnu/musl/uclibc define their own. Is it worth taking a crack at that?

[tgross35]

That would make sense, but I believe @farao ran libc-test and it wasn't actually usable with uclibc. I don't actually know why this would be though, so maybe I'm misunderstanding.

As long as somebody can confirm that the constant actually exists on our uclibc targets in C, I'm happy to take a PR adding it back.

[farao]

Here's my understanding that I got from a quick research: afaict, getting the minimum signal alt. stack size was traditionally done via the constant MINSIGSTKSZ and on more modern systems AT_MINSIGSTKSZ is used (or at least tried) for getting the minimum size at runtime (the kernel is supposed to pass that in the elf auxiliary vector and AT_MINSIGSTKSZ is the position in that vector).

uclibc (and uclibc-ng, the follow-up project that people usually mean nowadays when saying uclibc) does not specify AT_MINSIGSTKSZ unfortunately, but I guess that's only because nobody has added that yet. So imo there's a good chance that when defining it anyways (e.g. in the libc crate or elsewhere), that it's just usable because getauxval call will just get the value at that position in the vector.

[xtqqczze]

@wbx-github could uclibc-ng specify AT_MINSIGSTKSZ?

[skrap]

@wbx-github could uclibc-ng specify AT_MINSIGSTKSZ?

If this is possible, great, but we still need to make a path forward for existing versions of uclibc[-ng] which don't have this constant. I'm going to try to look at this today or tomorrow.

[tgross35]

If it's not for certain available in uclibc, it should be pretty easy to fix the std build if anyone is interested. Just add a target_env = "uclibc" option to the cfg that selects between these two functions https://github.com/rust-lang/rust/blob/e6b64a2f4c696b840f8a384ec28690eed6a5d267/library/std/src/sys/pal/unix/stack_overflow.rs#L308-L321

[xtqqczze]

If it's not for certain available in uclibc, it should be pretty easy to fix the std build if anyone is interested. Just add a target_env = "uclibc" option to the cfg that selects between these two functions https://github.com/rust-lang/rust/blob/e6b64a2f4c696b840f8a384ec28690eed6a5d267/library/std/src/sys/pal/unix/stack_overflow.rs#L308-L321

rust-lang/rust#154732

[skrap]

I've spent some of today trying to make armv7-unknown-linux-uclibceabihf work with the latest from https://toolchains.bootlin.com/. Since I last poked at this, there have been some changes to both uclibc as well as the libc crate which are making it more difficult to have the libc-test suite pass. However, I've got the full suite compiling and passing now!

In particular, a build of uclibc can be configured to use 64-bit time, or not. We won't know which configuration the underlying library has chosen, and it seems to me that we can't be compatible with both, as time_t and structs which include it change size and alignment, for example.

I think that this points to mirroring something like the RUST_LIBC_UNSTABLE_GNU_TIME_BITS or RUST_LIBC_UNSTABLE_MUSL_V1_2_3 environment variables. This would let developers targeting systems with new-ish uclibc build a toolchain which corresponds to their time_t and other uses of cfg(linux_time_bits64), while keeping compatibility "out of the box" with toolchains which have 32-bit time_t.

Thoughts on this? CC @lancethepants

[edited to remove paragraph which I reconsidered]

[skrap]

This branch builds and passes libc-test on both the following toolchains:

• armv7-eabihf--uclibc--bleeding-edge-2024.05-1 (last bootlin toolchain before time64 became the default)
• armv7-eabihf--uclibc--bleeding-edge-2025.08-1 with RUST_LIBC_UCLIBC_USE_TIME64=1 in the env, as this toolchain uses 64-bit time_t.

[tgross35]

I haven't looked at the fixes in detail but one note: I'd like to migrate from env to cfg so users can set it via RUSTFLAGS and not affect anything built on the host. So if you submit a PR, please do it similar to what's in #4977 (I need to get that over the line sometime soon).