`loongarch64-linux-musl` broken after libc v0.2.179

[heiher]

Reproduce

# Install cross
cargo install cross --git https://github.com/cross-rs/cross

# Create reproducer
cargo new hello
cd hello
cargo add gix-index

# Build
cross build --target loongarch64-unknown-linux-musl

Expected behavior

Build successful.

Unexpected behavior

error[E0609]: no field `st_mtime` on type `libc::stat`
  --> /home/hev/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/gix-index-0.46.0/src/fs.rs:58:34
   |
58 |             let seconds = self.0.st_mtime;
   |                                  ^^^^^^^^ unknown field
   |
help: a field with a similar name exists
   |
58 -             let seconds = self.0.st_mtime;
58 +             let seconds = self.0.st_mtim;
   |

I've bisected the issue to commit 55fa65b (PR #4463). That commit changes the member fields of struct stat based on the musl_v1_2_3 condition. Since musl_v1_2_3 is currently enabled for LoongArch64, while most libc users have not yet switched to the new fields, LoongArch64 ends up hitting build failures more easily than other targets.

Rust libc:

libc/src/unix/linux_like/linux/musl/b64/loongarch64/mod.rs

Lines 30 to 48 in 4b38c69

	#[cfg(not(musl_v1_2_3))]
	pub st_atime: crate::time_t,
	#[cfg(not(musl_v1_2_3))]
	pub st_atime_nsec: c_long,
	#[cfg(not(musl_v1_2_3))]
	pub st_mtime: crate::time_t,
	#[cfg(not(musl_v1_2_3))]
	pub st_mtime_nsec: c_long,
	#[cfg(not(musl_v1_2_3))]
	pub st_ctime: crate::time_t,
	#[cfg(not(musl_v1_2_3))]
	pub st_ctime_nsec: c_long,
	#[cfg(musl_v1_2_3)]
	pub st_atim: crate::timespec,
	#[cfg(musl_v1_2_3)]
	pub st_mtim: crate::timespec,
	#[cfg(musl_v1_2_3)]
	pub st_ctim: crate::timespec,

Upstream musl:
https://github.com/kraj/musl/blob/0784374d561435f7c787a555aeab8ede699ed298/arch/loongarch64/bits/stat.h#L14-L16

	struct timespec st_atim;
	struct timespec st_mtim;
	struct timespec st_ctim;

I think it makes sense to more toward musl_v1_2_3. However, we may need more time to properly prepare and align downstream users before fully enabling it.

How about introducing a new, more explicit condition (for example, musl_stat_use_timespec) and only enabling it for targets whose downstream is ready? Thanks!

cc @xbjfk @tgross35 @alexcrichton @martinetd

[huajingyun01]

Hello everyone, recently when upgrading packages in Alpine Linux, the LoongArch64 platform has started to be affected by this issue.
For example, jujutsu (libc v0.2.179 blocked gix-index) . Currently, some fixes have been made for LoongArch64 in gix-index(not gix-index upstream, just adding patche in Alpine), and the patch is similar to the following:

     pub fn modified(&self) -> Option<SystemTime> {
         #[cfg(not(windows))]
         {
-            #[cfg(not(any(target_os = "aix", target_os = "hurd")))]
+            #[cfg(not(any(target_os = "aix", target_os = "hurd", all(target_arch = "loongarch64", target_env = "musl"))))]
             let seconds = self.0.st_mtime;
-            #[cfg(any(target_os = "aix", target_os = "hurd"))]
+            #[cfg(any(target_os = "aix", target_os = "hurd", all(target_arch = "loongarch64", target_env = "musl")))]
             let seconds = self.0.st_mtim.tv_sec;
 
-            #[cfg(not(any(target_os = "aix", target_os = "hurd")))]
+            #[cfg(not(any(target_os = "aix", target_os = "hurd", all(target_arch = "loongarch64", target_env = "musl"))))]
             let nanoseconds = self.0.st_mtime_nsec;
-            #[cfg(any(target_os = "aix", target_os = "hurd"))]
+            #[cfg(any(target_os = "aix", target_os = "hurd", all(target_arch = "loongarch64", target_env = "musl")))]
             let nanoseconds = self.0.st_mtim.tv_nsec;

However, related projects continue to emerge, such as iamb (libc v0.2.180 blocked rustix) . More affected projects will continue to be exposed. It would be great if there were some changes from the libc upstream.
Thanks!