uclibc: fix build + CI, add unstable time64 support for newer uclibc toolchains by skrap · Pull Request #5046 · rust-lang/libc

skrap · 2026-04-07T14:58:04Z

Description

Goals of this change:

Fix uclibc build
Fix uclibc CI
support uclibc configurations which use a 64-bit time_t configuration, which is enabled on the latest bootlin toolchains.

Testing instructions

For testing, I have done the following:

build a custom rust toolchain against these changes (cherry-picked onto the libc-0.2 branch)
verified libc-test passes against the last bootlin toolchain to use 32-bit time_t (bleeding-edge-2024.02-1)
verified libc-test passes against the most recent bootlin toolchain (bleeding-edge-2025.08-1)
- This required setting RUSTFLAGS="--cfg=libc_unstable_uclibc_time64" as expected

Sources

I am not changing APIs so I don't think this applies.

Checklist

Relevant tests in libc-test/semver have been updated
No placeholder or unstable values like *LAST or *MAX are
included (see #3131)
- NOTE: I only included such values where semver required them.
Tested locally (cd libc-test && cargo test --target mytarget);
especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

skrap · 2026-04-07T17:03:29Z

+
+time64="$1"
+
+if [ "${time64:-0}" != "0" ]; then


I added this script to use a toolchain with or without 64-bit time_t depending on $1.

skrap · 2026-04-07T17:04:28Z

            "sys/fanotify.h",
-            // <sys/auxv.h> is not present on uclibc
-            (!uclibc, "sys/auxv.h"),
+            "sys/auxv.h",


uclibc has this header, at least in the toolchain versions in the CI.

skrap · 2026-04-07T17:05:10Z

-            // Not defined in uclibc as of 1.0.34
+            // Not defined in uclibc as of 1.0.45
            "gettid" if uclibc => true,
+            "getauxval" if uclibc => true,


libc doesn't define getauxval.

skrap · 2026-04-07T17:06:40Z

        pub nr: crate::__s32,
    }

-    #[cfg_attr(


Several definitions here were moved around in the linux/l4re shared restructuring. These are now defined elsewhere; remove them here.

skrap · 2026-04-07T17:07:19Z

 pub const EM_MN10300: u16 = 89;
 pub const EM_MN10200: u16 = 90;
 pub const EM_PJ: u16 = 91;
-#[cfg(not(target_env = "uclibc"))]


Many of these guarded constants are actually defined in uclibc. I removed guards where appropriate.

skrap · 2026-04-07T17:07:54Z

 pub const IP_ORIGDSTADDR: c_int = 20;
 pub const IP_RECVORIGDSTADDR: c_int = IP_ORIGDSTADDR;
 pub const IP_MINTTL: c_int = 21;
-#[cfg(not(target_env = "uclibc"))]


Similar removal of unnecessary guards.

skrap · 2026-04-07T17:15:48Z

CI seems to error on a rustc issue when building; I think this is unrelated. Awaiting a fix there, but feel free to review in the meantime!

tgross35 · 2026-04-08T04:24:33Z

+          - target: armv7-unknown-linux-uclibceabihf
+          - target: armv7-unknown-linux-uclibceabihf
+            env: { TEST_UCLIBC_TIIME64: 1 }


View changes since the review

This is fine for the purposes of this PR, but will need to get removed before merge; tier 2 vs. Tier 3 serves as the cutoff between what we do and don't test.

If you are interested in getting this target better tested and putting support behind that, please consider getting it upgraded to tier 2 :)

Gotcha, will remove. I don't know of anyone else in the world who uses this platform, so I don't think it's a good candidate for tier 2. I do have organizational support for maintaining this port but I worry that if this platform were promoted to tier 2 that any breakage would become a blocker to rust progress, and I would be a single point of failure.
(There are certainly other uclibc users, but none are tier 2. armv7 is obviously well-supported.)

Just noting that it's pretty easy to set up a downstream buildbot that runs tests - you can have an empty GitHub repo with a scheduled period CI job that clones this repo and tests. I think a few other T3 platforms do that.

tgross35 · 2026-04-08T04:31:37Z

-cfg_if! {
-    if #[cfg(not(target_env = "uclibc"))] {
-        pub const MFD_NOEXEC_SEAL: c_uint = 0x0008;
-        pub const MFD_EXEC: c_uint = 0x0010;
-        pub const MFD_HUGE_64KB: c_uint = 0x40000000;
-        pub const MFD_HUGE_512KB: c_uint = 0x4c000000;
-        pub const MFD_HUGE_1MB: c_uint = 0x50000000;
-        pub const MFD_HUGE_2MB: c_uint = 0x54000000;
-        pub const MFD_HUGE_8MB: c_uint = 0x5c000000;
-        pub const MFD_HUGE_16MB: c_uint = 0x60000000;
-        pub const MFD_HUGE_32MB: c_uint = 0x64000000;
-        pub const MFD_HUGE_256MB: c_uint = 0x70000000;
-        pub const MFD_HUGE_512MB: c_uint = 0x74000000;
-        pub const MFD_HUGE_1GB: c_uint = 0x78000000;
-        pub const MFD_HUGE_2GB: c_uint = 0x7c000000;
-        pub const MFD_HUGE_16GB: c_uint = 0x88000000;
-        pub const MFD_HUGE_MASK: c_uint = 63;
-        pub const MFD_HUGE_SHIFT: c_uint = 26;
-    }
-}
+pub const MFD_NOEXEC_SEAL: c_uint = 0x0008;
+pub const MFD_EXEC: c_uint = 0x0010;
+pub const MFD_HUGE_64KB: c_uint = 0x40000000;
+pub const MFD_HUGE_512KB: c_uint = 0x4c000000;
+pub const MFD_HUGE_1MB: c_uint = 0x50000000;
+pub const MFD_HUGE_2MB: c_uint = 0x54000000;
+pub const MFD_HUGE_8MB: c_uint = 0x5c000000;
+pub const MFD_HUGE_16MB: c_uint = 0x60000000;
+pub const MFD_HUGE_32MB: c_uint = 0x64000000;
+pub const MFD_HUGE_256MB: c_uint = 0x70000000;
+pub const MFD_HUGE_512MB: c_uint = 0x74000000;
+pub const MFD_HUGE_1GB: c_uint = 0x78000000;
+pub const MFD_HUGE_2GB: c_uint = 0x7c000000;
+pub const MFD_HUGE_16GB: c_uint = 0x88000000;
+pub const MFD_HUGE_MASK: c_uint = 63;
+pub const MFD_HUGE_SHIFT: c_uint = 26;


View changes since the review

@farao do the constants in this file that are changed here not exist on l4re? If so, they could just move to linux rather than linux_l4re_shared.

yes that's true they do not exist on l4re so they should rather be moved to linux. I think I only put them in here to have all the MFD_* consts in one file.

What about the constants like EM_OPENRISC or PTHREAD_MUTEX_STALLED above?

@skrap for the constants here, could you update them to not(target_os = "l4re") rather than removing the gate? I think that's easier than moving them all.

Maybe also with a comment that this is done to keep similar constants in the same file

Re EM_OPENRISC:

Some of these are a bit unexpected to have live in libc, to be honest. The EM_* constants are defined not by libc or by the kernel, but by the ELF format spec. They're fixed no matter what OS or std library we're running. So for this constant, I would prefer that libc present a unified interface to higher-level crates, rather than adopt the uclibc quirk of having EM_OR1K be a synonym for EM_OPENRISC.

Re PTHREAD_MUTEX_STALLED:
I'm not sure I understand the question here. This constant isn't conditional based on the target_env.

could you update them to not(target_os = "l4re")

I think your request is reasonable, but I would like to ask that the requested l4re change go into a separate PR, as removing those constants for the l4re build could easily introduce breakage, and I don't know anything about that platform.

To answer the question a few comments above: yes, all constants that were disabled for uclibc are not present on l4re. I would of course prefer if they stayed disabled for l4re in one way or the other

@skrap I would accept breakage here as there shouldn't exist real user on l4re give the comments from Marius. Could you address the suggestion?

tgross35 · 2026-04-08T04:38:36Z

+            "ALG_SET_KEY_BY_KEY_SERIAL"
+            | "AT_MINSIGSTKSZ"
+            | "BUS_MCEERR_AO"
+            | "BUS_MCEERR_AR"
+            | "CAN_BUS_OFF_THRESHOLD"
+            | "CAN_CTRLMODE_TDC_AUTO"
+            | "CAN_CTRLMODE_TDC_MANUAL"
+            | "CAN_ERR_CNT"


View changes since the review

It seems like many of these should be fine if included via linux/... .h paths; is there a reason that isn't recommended or doesn't work on uclibc?

If so, it would be good to mark them deprecated on the target and remove in a release or two.

I can do that.

I was unsure of the philosophy here with respect to kernel-defined constants. They would either be present in linux/*.h headers or not depending on the kernel version, regardless of whatever libc library/version was being used on the system. So what triggers a particular constant being promoted into the libc crate?

I included the constants via linux UAPI headers as much as possible, but in some cases doing so conflicted with the definitions from uclibc. In this case, I left a comment.

In order to increase readability, I moved the uclibc-specific handling of exceptions to its own code branch and out of the catch-all branch, mirroring how musl does things.

I was unsure of the philosophy here with respect to kernel-defined constants. They would either be present in linux/*.h headers or not depending on the kernel version, regardless of whatever libc library/version was being used on the system. So what triggers a particular constant being promoted into the libc crate?

We assume a recent kernel, which for most platforms is usually whatever GitHub Actions gives us. API may be added whenever it's in a released kernel, might just need a test skip if we're testing with something older.

skrap · 2026-04-08T17:38:30Z

I addressed the review feedback. Thanks for having a look!

I had to fence out POSIX_SPAWN_SETSID under target_env = uclibc. This is a GNU-only constant and is not implemented in uclibc. It was mistakenly included.

skrap · 2026-04-13T00:52:41Z

@tgross35 I am unsure of the desired workflow here - I see a "request re-review" button in the github UI. Is this on your plate already, or do I push that button now that I have addressed your feedback? (Not trying to rush, just trying to learn the intended workflow.)

tgross35

Think the todo list here should be about the last one, also some questions.

@tgross35 I am unsure of the desired workflow here - I see a "request re-review" button in the github UI. Is this on your plate already, or do I push that button now that I have addressed your feedback? (Not trying to rush, just trying to learn the intended workflow.)

You can request a review. Usually I just go based on labels but requesting a review should also flip to S-waiting-on-review IIRC (as does @rustbot review).

The cycle is a bit slow for libc for nontrivial PRs, typically I go through everything every ~2 weeks.

View changes since this review

tgross35 · 2026-04-13T08:12:05Z

-cfg_if! {
-    if #[cfg(not(target_env = "uclibc"))] {
-        pub const MFD_NOEXEC_SEAL: c_uint = 0x0008;
-        pub const MFD_EXEC: c_uint = 0x0010;
-        pub const MFD_HUGE_64KB: c_uint = 0x40000000;
-        pub const MFD_HUGE_512KB: c_uint = 0x4c000000;
-        pub const MFD_HUGE_1MB: c_uint = 0x50000000;
-        pub const MFD_HUGE_2MB: c_uint = 0x54000000;
-        pub const MFD_HUGE_8MB: c_uint = 0x5c000000;
-        pub const MFD_HUGE_16MB: c_uint = 0x60000000;
-        pub const MFD_HUGE_32MB: c_uint = 0x64000000;
-        pub const MFD_HUGE_256MB: c_uint = 0x70000000;
-        pub const MFD_HUGE_512MB: c_uint = 0x74000000;
-        pub const MFD_HUGE_1GB: c_uint = 0x78000000;
-        pub const MFD_HUGE_2GB: c_uint = 0x7c000000;
-        pub const MFD_HUGE_16GB: c_uint = 0x88000000;
-        pub const MFD_HUGE_MASK: c_uint = 63;
-        pub const MFD_HUGE_SHIFT: c_uint = 26;
-    }
-}
+pub const MFD_NOEXEC_SEAL: c_uint = 0x0008;
+pub const MFD_EXEC: c_uint = 0x0010;
+pub const MFD_HUGE_64KB: c_uint = 0x40000000;
+pub const MFD_HUGE_512KB: c_uint = 0x4c000000;
+pub const MFD_HUGE_1MB: c_uint = 0x50000000;
+pub const MFD_HUGE_2MB: c_uint = 0x54000000;
+pub const MFD_HUGE_8MB: c_uint = 0x5c000000;
+pub const MFD_HUGE_16MB: c_uint = 0x60000000;
+pub const MFD_HUGE_32MB: c_uint = 0x64000000;
+pub const MFD_HUGE_256MB: c_uint = 0x70000000;
+pub const MFD_HUGE_512MB: c_uint = 0x74000000;
+pub const MFD_HUGE_1GB: c_uint = 0x78000000;
+pub const MFD_HUGE_2GB: c_uint = 0x7c000000;
+pub const MFD_HUGE_16GB: c_uint = 0x88000000;
+pub const MFD_HUGE_MASK: c_uint = 63;
+pub const MFD_HUGE_SHIFT: c_uint = 26;


What about the constants like EM_OPENRISC or PTHREAD_MUTEX_STALLED above?

@skrap for the constants here, could you update them to not(target_os = "l4re") rather than removing the gate? I think that's easier than moving them all.

tgross35 · 2026-04-13T08:12:31Z

-cfg_if! {
-    if #[cfg(not(target_env = "uclibc"))] {
-        pub const MFD_NOEXEC_SEAL: c_uint = 0x0008;
-        pub const MFD_EXEC: c_uint = 0x0010;
-        pub const MFD_HUGE_64KB: c_uint = 0x40000000;
-        pub const MFD_HUGE_512KB: c_uint = 0x4c000000;
-        pub const MFD_HUGE_1MB: c_uint = 0x50000000;
-        pub const MFD_HUGE_2MB: c_uint = 0x54000000;
-        pub const MFD_HUGE_8MB: c_uint = 0x5c000000;
-        pub const MFD_HUGE_16MB: c_uint = 0x60000000;
-        pub const MFD_HUGE_32MB: c_uint = 0x64000000;
-        pub const MFD_HUGE_256MB: c_uint = 0x70000000;
-        pub const MFD_HUGE_512MB: c_uint = 0x74000000;
-        pub const MFD_HUGE_1GB: c_uint = 0x78000000;
-        pub const MFD_HUGE_2GB: c_uint = 0x7c000000;
-        pub const MFD_HUGE_16GB: c_uint = 0x88000000;
-        pub const MFD_HUGE_MASK: c_uint = 63;
-        pub const MFD_HUGE_SHIFT: c_uint = 26;
-    }
-}
+pub const MFD_NOEXEC_SEAL: c_uint = 0x0008;
+pub const MFD_EXEC: c_uint = 0x0010;
+pub const MFD_HUGE_64KB: c_uint = 0x40000000;
+pub const MFD_HUGE_512KB: c_uint = 0x4c000000;
+pub const MFD_HUGE_1MB: c_uint = 0x50000000;
+pub const MFD_HUGE_2MB: c_uint = 0x54000000;
+pub const MFD_HUGE_8MB: c_uint = 0x5c000000;
+pub const MFD_HUGE_16MB: c_uint = 0x60000000;
+pub const MFD_HUGE_32MB: c_uint = 0x64000000;
+pub const MFD_HUGE_256MB: c_uint = 0x70000000;
+pub const MFD_HUGE_512MB: c_uint = 0x74000000;
+pub const MFD_HUGE_1GB: c_uint = 0x78000000;
+pub const MFD_HUGE_2GB: c_uint = 0x7c000000;
+pub const MFD_HUGE_16GB: c_uint = 0x88000000;
+pub const MFD_HUGE_MASK: c_uint = 63;
+pub const MFD_HUGE_SHIFT: c_uint = 26;


Maybe also with a comment that this is done to keep similar constants in the same file

tgross35 · 2026-04-13T08:16:20Z

+                /*
+                Here are a list of kernel UAPI constants which appear in linux/ headers,
+                but cannot be imported due to conflicts with the uclibc headers.
+                The conflicting linux/ header is noted.
+                 */


What is the expected flow for these when you're writing C if there are conflicts?

My view on it is that these constants are passed through the underlying target_env and to the kernel, rather than invoking specific behavior within the target_env c std lib. For constants where this is true, it means that they're safe and appropriate to use regardless of whether the c std lib re-exports them or not. The case where they could lead to unintentional bad behavior is when the c std lib needed to change behavior based on the constant. I am not individually researching and testing each of these, so it's possible that there's a bug here, but I would like to consider those issues as outside the scope of this PR. (This is just moving around these constants and fixing the build.)

To answer your question, if I were writing a piece of C code and needed one of these constants, I would probably find a way to untangle the header mess or just copy the #define into my implementation. Ugly, yes, but this is the state of system headers in C in my experience.

There are also of other examples in libc-test/build.rs of this type of issue - e.g. see test_linux_like_apis() which appears to try to work around this issue for combinations of specific constants and headers which don't work.

tgross35 · 2026-04-13T08:22:15Z

+else
+    version='bleeding-edge-2024.05-1'  # last version with 32-bit time_t
+fi


Does this more or less mean that you're stuck on an old uclibc version if you want to use time APIs? There aren't the duplicate symbols and header config like glibc has?

If so, I think we could flip the default at some point in the near future. Technically breaking but we can get away with it on T3 targets, and musl and glibc aren't quite as stuck.

Ah, no - let me explain. uClibc is intended for use on embedded devices where space (and thus code size) is at a premium. A developer would typically build their own uclibc with only the features required for their use case. uclibc facilitates this customization by having a configuration step (via a menuconfig, like the kernel menuconfig system, if you've ever used that) where the developer chooses the features they like, including whether to use a 32-bit or 64-bit time_t, and then builds their own uclibc for their project.

So we cannot say for sure within the libc crate which size of time_t will be present in the underlying uclibc library.

The bootlin folks have chosen to enable the 64-bit time_t feature on their build of uclibc as of the toolchain noted above. Having a reference toolchain is really useful for ease of CI and developer bootstrapping purposes, but the uclibc configuration choices that the bootlin toolchain makes aren't necessarily the same (nor binary compatible) with any other developer's use of uclibc.

This is why I expect everyone using uclibc with rust ends up either using -Zbuild-std or building their own cross toolchain, in either case targeting their project-specific uclibc headers, and (as of this change) making use of the --cfg=libc_unstable_uclibc_time64 rustflag if needed.

My feeling is this unfortunately isn't very sustainable. It's not ideal to have all the old kernel version skips in build.rs, they're going to be perpetually out of date.

How hard is it to build uclibc? We're already building musl from source, doing the same here would probably be best.

No need to do that in this PR but I do think you should drop the 2024.02-1 option from this script, and any test skips that go along with it. Then switch to building from source in a followup.

It's definitely feasible to build uclibc in CI. I can take this as a task for a future improvement, especially if some uclibc target would ever become tier 2. Right now I can't really figure out how to make the Docker script work, however, so I will leave it as vestigial.

(In case it matters, the issue I'm hitting is that the macro expansion code in libc-test is complaining that rustc fails with can't find crate for core, which presumably can be made to work since tier 2 platforms work, but I'm not sure how! If you have insights I'll make it work in a separate PR.)

I would really like to get this change in, so would you please accept the PR without me going back and re-auditing each kernel constant? It is really time consuming, and isn't a standard which is applied to any other target's script, as far as I can tell. I would be happy to do so in a future PR.

Alternatively, I could just delete the CI infrastructure associated with this target, as it cannot work and is not run.

(In case it matters, the issue I'm hitting is that the macro expansion code in libc-test is complaining that rustc fails with can't find crate for core, which presumably can be made to work since tier 2 platforms work, but I'm not sure how! If you have insights I'll make it work in a separate PR.)

The T2 targets have dist artifacts so we can just use rustup, which happens here

libc/ci/install-rust.sh

Lines 27 to 28 in d73763f

rustup update --force "$toolchain" --no-self-update

rustup default "$toolchain"

. You'll need to make sure Cargo is getting -Zbuild-std=core, can you see if setting this env works?

libc/ci/run.sh

Line 20 in d73763f

cmd="cargo test --target $target ${LIBC_CI_ZBUILD_STD+"-Zbuild-std"}"

I would really like to get this change in, so would you please accept the PR without me going back and re-auditing each kernel constant? It is really time consuming, and isn't a standard which is applied to any other target's script, as far as I can tell. I would be happy to do so in a future PR.

Alternatively, I could just delete the CI infrastructure associated with this target, as it cannot work and is not run.

No audit needed, I meant that you should delete the skips under "The canonical uClibc toolchain, bootlin bleeding-edge-2024.02-1, uses linux 5.15, so several constants are not available." since nothing else in the build script needs to be updated for a kernel that old.

But that's all fair enough, this has been waiting a while so I'll apply it. Just send the CI PR when you have it ready.

rustbot · 2026-04-13T08:27:46Z

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

tgross35 · 2026-04-13T08:31:34Z

+cfg_if! {
+    // Set cfg(libc_unstable_uclibc_time64) in rustflags if your uclibc has 64-bit time
+    if #[cfg(linux_time_bits64)] {
+        pub type time_t = c_longlong;
+        pub type suseconds_t = c_longlong;
+    } else {
+        pub type time_t = c_long;
+        pub type suseconds_t = c_long;
+    }
+}


View changes since the review

Do any structs need to be updated here? I know on other targets the padding in the timespec struct sometimes needs to be adjusted. I assume there are no function link names to update if uclibc had a pretty clean cut 32->64 transition.

I am relying on the libc-test infrastructure a bit here to catch errors, but I think everything should be OK. I am happy to be the point person for any issues raised for 64-bit time_t in uclibc, if bugs are reported.

skrap

@rustbot ready

Thanks for the review! I have replied inline to the issues raised.

View changes since this review

tgross35

I have one last thing, I think we should drop the time32 test config because it's literally always going to be failing. But after that, diff LGTM. Please squash the "Addressing review feedback" commit into one of the previous commits.

Very sorry about the delay here, I had pretty much no time to review anything the past couple of months. I should be back now.

View changes since this review

tgross35 · 2026-06-19T06:12:34Z

+else
+    version='bleeding-edge-2024.05-1'  # last version with 32-bit time_t
+fi


My feeling is this unfortunately isn't very sustainable. It's not ideal to have all the old kernel version skips in build.rs, they're going to be perpetually out of date.

How hard is it to build uclibc? We're already building musl from source, doing the same here would probably be best.

No need to do that in this PR but I do think you should drop the 2024.02-1 option from this script, and any test skips that go along with it. Then switch to building from source in a followup.

tgross35 · 2026-06-19T06:33:08Z

+    let uclibc_use_time64 = env::var("CARGO_CFG_LIBC_UNSTABLE_UCLIBC_TIME64")
+        .map(|val| val != "0")
+        .unwrap_or(false);


For libc 1.0 I'd like the default to be 64-bit time_t on all platforms that support it, so if it's going to be valuable to continue supporting 32-bit then I think might be better as CARGO_CFG_LIBC_UNSTABLE_UCLIBC_TIME_BITS eventually, set to either "32" or "64".

No need to do this change here, just an FYI for the future.

Thanks, noted. I'm fine with this plan.

tgross35 · 2026-06-19T06:45:05Z

+          - target: armv7-unknown-linux-uclibceabihf
+          - target: armv7-unknown-linux-uclibceabihf
+            env: { TEST_UCLIBC_TIIME64: 1 }


Just noting that it's pretty easy to set up a downstream buildbot that runs tests - you can have an empty GitHub repo with a scheduled period CI job that clones this repo and tests. I think a few other T3 platforms do that.

tgross35 · 2026-06-19T06:53:27Z

+            "ALG_SET_KEY_BY_KEY_SERIAL"
+            | "AT_MINSIGSTKSZ"
+            | "BUS_MCEERR_AO"
+            | "BUS_MCEERR_AR"
+            | "CAN_BUS_OFF_THRESHOLD"
+            | "CAN_CTRLMODE_TDC_AUTO"
+            | "CAN_CTRLMODE_TDC_MANUAL"
+            | "CAN_ERR_CNT"


I was unsure of the philosophy here with respect to kernel-defined constants. They would either be present in linux/*.h headers or not depending on the kernel version, regardless of whatever libc library/version was being used on the system. So what triggers a particular constant being promoted into the libc crate?

We assume a recent kernel, which for most platforms is usually whatever GitHub Actions gives us. API may be added whenever it's in a released kernel, might just need a test skip if we're testing with something older.

tgross35 · 2026-06-19T07:01:03Z

@@ -0,0 +1,20 @@
+#!/usr/bin/bash


Sorry, one other thing: just use #!/bin/bash, the path under usr isn't available on all platforms.

View changes since the review

…is a gnu-ism

rustbot · 2026-06-19T21:16:10Z

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.

skrap · 2026-06-19T21:18:27Z

Addressed much of the feedback, but did not alter the libc test yet. I will do so in a future PR.

@rustbot review

tgross35

Thank you for the changes!

View changes since this review

tgross35 · 2026-06-19T23:34:36Z

+else
+    version='bleeding-edge-2024.05-1'  # last version with 32-bit time_t
+fi


(In case it matters, the issue I'm hitting is that the macro expansion code in libc-test is complaining that rustc fails with can't find crate for core, which presumably can be made to work since tier 2 platforms work, but I'm not sure how! If you have insights I'll make it work in a separate PR.)

The T2 targets have dist artifacts so we can just use rustup, which happens here

libc/ci/install-rust.sh

Lines 27 to 28 in d73763f

rustup update --force "$toolchain" --no-self-update

rustup default "$toolchain"

. You'll need to make sure Cargo is getting -Zbuild-std=core, can you see if setting this env works?

libc/ci/run.sh

Line 20 in d73763f

cmd="cargo test --target $target ${LIBC_CI_ZBUILD_STD+"-Zbuild-std"}"

I would really like to get this change in, so would you please accept the PR without me going back and re-auditing each kernel constant? It is really time consuming, and isn't a standard which is applied to any other target's script, as far as I can tell. I would be happy to do so in a future PR.

Alternatively, I could just delete the CI infrastructure associated with this target, as it cannot work and is not run.

No audit needed, I meant that you should delete the skips under "The canonical uClibc toolchain, bootlin bleeding-edge-2024.02-1, uses linux 5.15, so several constants are not available." since nothing else in the build script needs to be updated for a kernel that old.

But that's all fair enough, this has been waiting a while so I'll apply it. Just send the CI PR when you have it ready.

rustbot added A-CI Area: CI-related items stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels Apr 7, 2026

skrap force-pushed the main branch from cb40fdd to f818e4f Compare April 7, 2026 17:01

skrap commented Apr 7, 2026

View reviewed changes

skrap force-pushed the main branch from f818e4f to d234f7d Compare April 7, 2026 17:18

skrap marked this pull request as ready for review April 7, 2026 17:20

rustbot added the S-waiting-on-review label Apr 7, 2026

skrap mentioned this pull request Apr 7, 2026

uclibc: cannot find value AT_MINSIGSTKSZ #5039

Closed

tgross35 reviewed Apr 8, 2026

View reviewed changes

skrap force-pushed the main branch from c309140 to 8f8451e Compare April 8, 2026 16:40

This comment has been minimized.

Sign in to view

tgross35 requested changes Apr 13, 2026

View reviewed changes

rustbot added S-waiting-on-author and removed S-waiting-on-review labels Apr 13, 2026

tgross35 reviewed Apr 13, 2026

View reviewed changes

skrap commented Apr 13, 2026

View reviewed changes

rustbot added S-waiting-on-review and removed S-waiting-on-author labels Apr 13, 2026

skrap force-pushed the main branch from 8f8451e to 427ec9b Compare April 13, 2026 14:57

This comment has been minimized.

Sign in to view

skrap requested a review from tgross35 April 30, 2026 00:07

rustbot added the S-waiting-on-review label Jun 14, 2026

JohnTitor mentioned this pull request Jun 14, 2026

MFD_HUGE_* / MFD_NOEXEC_SEAL / MFD_EXEC are not defined for uClibc targets #5163

Closed

skrap force-pushed the main branch from 4832277 to d67676d Compare June 14, 2026 22:17

This comment has been minimized.

Sign in to view

skrap force-pushed the main branch from d67676d to c26e152 Compare June 15, 2026 13:31

This comment has been minimized.

Sign in to view

skrap force-pushed the main branch from c26e152 to 80adb5b Compare June 17, 2026 02:00

This comment has been minimized.

Sign in to view

skrap force-pushed the main branch from 80adb5b to cc02669 Compare June 18, 2026 20:37

This comment has been minimized.

Sign in to view

tgross35 requested changes Jun 19, 2026

View reviewed changes

rustbot added S-waiting-on-author and removed S-waiting-on-review labels Jun 19, 2026

tgross35 reviewed Jun 19, 2026

View reviewed changes

tgross35 mentioned this pull request Jun 19, 2026

linux(uclibc): add cfg option for file offset bindings on 32-bit targets #5165

Open

3 tasks

Jonah Petri added 3 commits June 19, 2026 17:15

uclibc: fix build, enable CI, add unstable support of 64-bit time_t

0072003

semver: move POSIX_SPAWN_SETSID from linux -> linux-{gnu,musl} as it …

c1a84a0

…is a gnu-ism

uclibc: fix type of PRIO_PROCESS and friends

6fcae12

skrap force-pushed the main branch from cc02669 to 6fcae12 Compare June 19, 2026 21:16

rustbot added S-waiting-on-review and removed S-waiting-on-author labels Jun 19, 2026

tgross35 approved these changes Jun 19, 2026

View reviewed changes

tgross35 added this pull request to the merge queue Jun 19, 2026

Merged via the queue into rust-lang:main with commit 24952f3 Jun 19, 2026
52 checks passed

rustbot removed the S-waiting-on-review label Jun 19, 2026

This was referenced Jun 19, 2026

fix: deprecate/fix time_t family types under Windows x86 GNU on stable #5062

Open

linux(uclibc): move definition of time_t #5144

Open

	rustup update --force "$toolchain" --no-self-update
	rustup default "$toolchain"

Conversation

skrap commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Testing instructions

Sources

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

skrap commented Apr 7, 2026

Uh oh!

tgross35 Apr 8, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tgross35 Apr 8, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

skrap Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

tgross35 Apr 8, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

skrap Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

skrap commented Apr 8, 2026

Uh oh!

skrap commented Apr 13, 2026

Uh oh!

tgross35 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

skrap commented Apr 7, 2026 •

edited

Loading

tgross35 Apr 8, 2026 •

edited by rustbot

Loading

tgross35 Apr 8, 2026 •

edited by rustbot

Loading

skrap Apr 13, 2026 •

edited

Loading

tgross35 Apr 8, 2026 •

edited by rustbot

Loading

skrap Apr 8, 2026 •

edited

Loading

tgross35 left a comment •

edited by rustbot

Loading

skrap Apr 13, 2026 •

edited

Loading

tgross35 Apr 13, 2026 •

edited by rustbot

Loading

skrap left a comment •

edited by rustbot

Loading

tgross35 left a comment •

edited

Loading