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

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

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.

Thanks, but the macro expansion is not done via cargo build, but rather rustc directly, so the -Zbuild-std flag is not available. See ctest/src/macro_expansion.rs for where this is done.

I don't understand how this could work without a built std lib. Do you know?

Ah, I didn't realize that was what was failing. I'm not really sure what's best there. Maybe invoking via cargo rustc rather than rustc directly would work?

Tried that already, sadly. :( no dice.

It seems like that should work, what failed?

If you wouldn't mind creating a new issue for this, that would probably be ideal so it doesn't get lost here.

Filed #5204
Thanks for the help on this!

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.

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

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.

libc doesn't define getauxval.