crate: expose `cfg` for general 64-bit `time_t` functionality by dybucc · Pull Request #5411 · rust-lang/libc

dybucc · 2026-08-14T14:00:37Z

Description

This patch adds support for a new cfg for easily toggling support for
64-bit time_t in supported platforms. This really only sets up the any
one of linux_time_bits64, gnu_time_bits64 or uclibc_time64.

The name of the cfg is time64.

Note support for the equivalent flag in musl has not been included
because we already have set-up automatic detection and toggling of the
corresponding cfg under supported targets ¹.

Checklist

Relevant tests in libc-test/semver have been updated
Commit messages permalink to headers for added or changed API
Placeholder or unstable values like *LAST or *MAX have the
standard doc comment
Tested locally (cargo test -p libc-test --target mytarget);
especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

https://github.com/rust-lang/libc/blob/1a8e71f33b1d6ea1e072210e7fc994417bbb2e34/build.rs#L181-L190 ↩

tgross35

Could you also update CI to use this cfg rather than the current glibc/musl cfg? Since this is what we're most likely to ship, we should make sure it works.

View changes since this review

rustbot · 2026-08-25T08:31:11Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

dybucc · 2026-08-29T10:00:07Z

I think it's done now. While checking through the CI workflow file, I
noticed that we even though we set the "updated but deprecated"
RUST_LIBC_UNSTABLE_MUSL_V1_2 environment variable for certain targets
¹, we still check for RUSTC_LIBC_UNSTABLE_MUSL_V1_2_3 in build.rs
².

I was wondering what's our stance on that change for stable releases,
and whether we should even set the deprecated environment variable in
CI. It seems wrong.

@rustbot ready

tgross35

Two small things then LGTM

View changes since this review

dybucc · 2026-09-01T14:57:17Z

Wondering if you saw ¹, @tgross35?

@rustbot ready

https://github.com/rust-lang/libc/pull/5411#issuecomment-5461679894 ↩

tgross35 · 2026-09-04T09:31:42Z

I think it's done now. While checking through the CI workflow file, I noticed that we even though we set the "updated but deprecated" RUST_LIBC_UNSTABLE_MUSL_V1_2 environment variable for certain targets 1, we still check for RUSTC_LIBC_UNSTABLE_MUSL_V1_2_3 in build.rs 2.

I was wondering what's our stance on that change for stable releases, and whether we should even set the deprecated environment variable in CI. It seems wrong.

Oh, I did mean to update main.yaml here. Could you do that?

I'm not sure I follow the rest, why do you consider RUST_LIBC_UNSTABLE_MUSL_V1_2 "updated but deprecated"? And what do we need to take a stance on regarding stable releases?

tgross35 · 2026-09-07T08:19:26Z

Could you rebase this once #5508 lands? let musl_v1_2 = ..., let uclibc_time64 = ..., and let gnu32_time64.

tgross35 · 2026-09-07T08:20:00Z

Also please update the commit summary and PR title to mention the name of the config, it doesn't actually show up anywhere except the env form :)

tgross35 · 2026-09-19T18:31:47Z

@dybucc There's still a test failure here, and could you please add the full cfg name to the commit summary? #5411 (comment)

tgross35

(status update)

View changes since this review

dybucc · 2026-09-20T06:49:10Z

@dybucc There's still a test failure here, and could you please add the
full cfg name to the commit summary?
#5411 (comment)

Done, except the test. Sorry, I checked off this PR from my list of
pending stuff without properly finishing work on it. The test failure
seems odd; This PR introduced no changes that should make it fail.

The assertion about the linux_time_bits64 cfg being only valid for
Linux may be too restrictive. This is currently set in main also for
targets using uClibc ¹.

The reason why this might not be popping up in CI workflow runs across
other PRs is because there is already another (likely unrelated) CI
failure concerning an AIX target. L4Re tests haven't run at that point.

https://github.com/rust-lang/libc/blob/35c8b7d847f64265cb578343dc5d1be467fe63db/build.rs#L265-L269 ↩

tgross35 · 2026-09-20T08:33:29Z

AIX is probably rust-lang/rust#162979, feel free to add a commit disabling that with a FIXME for now.

The assertion about the linux_time_bits64 cfg being only valid for Linux may be too restrictive. This is currently set in main also for targets using uClibc 1.

The reason why this might not be popping up in CI workflow runs across other PRs is because there is already another (likely unrelated) CI failure concerning an AIX target. L4Re tests haven't run at that point.

Is that one failing? I didn't notice it hitting any error last time I ran check-all-targets, but that wasn't super recent.

I guess uclibc should have its own cfg independent of Linux, like glibc does. Or we could merge more cfgs together in the future after this single-cfg option is around for a bit.

dybucc · 2026-09-20T10:11:14Z

AIX is probably rust-lang/rust#162979, feel
free to add a commit disabling that with a FIXME for now.

Just commented out the AIX target from being checked in CI.

I guess uclibc should have its own cfg independent of Linux, like glibc
does. Or we could merge more cfgs together in the future after this
single-cfg option is around for a bit.

I've made available a new cfg for uClibc targets. This may need
further discussion, so for now it continues to use the same Linux cfg
in code, but the build script differentiates from uClibc.

Back when this was introduced, there were no issues with the uClibc
targets setting up a seemingly Linux-only flag ¹.

https://github.com/rust-lang/libc/pull/5046/changes#diff-aedce4e8d381f53dae77653609e3174da7ee2a184308251ad33f7a47bebabe14R3755-R3760 ↩

xtqqczze · 2026-09-20T10:21:52Z

+        with:
+          persist-credentials: false
+      - name: Install Rust
+        # FIXME(rust-lang/rust#160439): unpin once the issue is fixed


nit: can we include full URL: https://github.com/rust-lang/rust/pull/162979, makes navigation a bit easier.

View changes since the review

I wouldn't do that simply because there's other FIXME comments
throughout the codebase already using this style. I think only when the
links are outside GitHub is it that full links are included.

If we were to include the full link, though, I would think it best to
not include it in between parenthesis, but rather as part of the comment
"body" (e.g. FIXME: see <link-here>.)

(If that's the GitHub PR extension for VSCode, I think there's a setting
for it to attempt to link to the right issue when detecting these
shortforms in any file.)

I think using a format like rust-lang/rust#160439 is generally over-indexing on GitHub. I don't think readers should need to configure an extension just to make the reference navigable.

I digress but, of course, this is open source, so be my guest.

By the way, since rust-lang/rust#162979 was recently merged, is this pin expected to be removable once nightly-2026-09-20 is released, or is there another issue that still needs to be addressed?

I don't think the issue the comment ¹ mentions is related to
rust-lang/rust#162979.

Footnotes

cargo doc freezes on libc with nightly-2026-08-03 rust#160439 ↩

tgross35 · 2026-09-20T22:01:53Z

Cherry picked the AIX skip as #5541 to unblock other things

Add `cfg` enabling `time64` functionality across all supported targets. This ensures users have a simple entry point to the crate functionality gated behind one of `linux_time_bits64`, `uclibc_time64` and `gnu_time_bits64`. The new `cfg` goes by the name `libc_unstable_time64`.

Switch as many uses of other target-specific `cfg`s with the `time64` `cfg` introduced in the prior patch.

- Change indentation of two YAML arrays to consistently appear as nested within the key that corresponds with the array. - Change one inconsistent use of single quotes with double quotes for YAML strings.

Replace use of `RUST_LIBC_UNSTABLE_MUSL_V1_2` with `TEST_MUSL_V1_2` in the PowerPC CI runs. The former is deprecated; The latter is used in CI scripts to set the right unstable `cfg` for functionality gated behind musl's v1.2.

rustbot · 2026-09-21T07:19:13Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

tgross35

Sorry for the conflict but I think that should resolve the uclibc issue. LGTM assuming CI passes

View changes since this review

rustbot added S-waiting-on-review stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels Aug 14, 2026

tgross35 requested changes Aug 25, 2026

View reviewed changes

Comment thread build.rs Outdated

Comment thread build.rs Outdated

rustbot added S-waiting-on-author and removed S-waiting-on-review labels Aug 25, 2026

dybucc force-pushed the time64-global-cfg branch from 98e48b9 to 1ab4287 Compare August 29, 2026 06:37