musl: Change time_t definition on 32-bit targets according to "time64"

[JohnTitor]

time_t is defined as c_long on musl:

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

Line 3 in b1268e4

pub type time_t = c_long;

and c_long is i32 on 32-bit targets:

libc/src/unix/linux_like/linux/musl/b32/mod.rs

Line 1 in b1268e4

pub type c_long = i32;

But the time_t definition has been changed to 64-bit by bminor/musl@3814333, since musl 1.2.0.
We will change our type to i64 on 32-bit targets as well at some point but we should announce it before changing.
cc #1846

[mahkoh]

Isn't this broken either way as soon as C libraries are involved or am I missing something?

As documented in time64.html, C code compiled against >=1.2 assumes time_t = i64 whereas code compiled against <1.2 assumes time_t = i32 on 32 bit systems. If you use a C library that uses time_t in its interface (e.g. openssl), the time_t used by rust code must have the same size as in the musl headers.

[abcfy2]

Any updates? I'm facing the same issue when building openssl:

   Compiling shadowsocks-rust v1.8.19 (/project)
error: linking with `arm-linux-musleabi-gcc` failed: exit code: 1
  |
  = note: "arm-linux-musleabi-gcc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-Wl,--eh-frame-hdr" "-nostartfiles" "/rust/lib/rustlib/arm-unknown-linux-musleabi/lib/self-contained/crt1.o" "/rust/lib/rustlib/arm-unknown-linux-musleabi/lib/self-contained/crti.o" "-L" "/rust/lib/rustlib/arm-unknown-linux-musleabi/lib" "-L" "/rust/lib/rustlib/arm-unknown-linux-musleabi/lib/self-contained" "/target/arm-unknown-linux-musleabi/release/deps/ssurl-b511399b1b3e9edd.ssurl.1o5mikv8-cgu.0.rcgu.o" "-o" "/target/arm-unknown-linux-musleabi/release/deps/ssurl-b511399b1b3e9edd" "-Wl,--gc-sections" "-static" "-no-pie" "-Wl,-zrelro" "-Wl,-znow" "-Wl,-O1" "-nodefaultlibs" "-L" "/target/arm-unknown-linux-musleabi/release/deps" "-L" "/target/release/deps" "-L" "/target/arm-unknown-linux-musleabi/release/build/libsodium-sys-af7e3974b41e2f39/out/installed/lib" "-L" "/target/arm-unknown-linux-musleabi/release/build/openssl-sys-ddefbd6d719725b9/out/openssl-build/install/lib" "-L" "/target/arm-unknown-linux-musleabi/release/build/ring-c1bb5f055649313e/out" "-L" "/rust/lib/rustlib/arm-unknown-linux-musleabi/lib" "-Wl,-Bstatic" "/tmp/rustc2sPxVB/libring-7676a44ad52e73ec.rlib" "/tmp/rustc2sPxVB/liblibsodium_sys-8f2b5176646fe1cb.rlib" "/tmp/rustc2sPxVB/libopenssl_sys-0f67a64037e617dd.rlib" "-Wl,--start-group" "/tmp/rustc2sPxVB/libunwind-bb2d2101beb6f64d.rlib" "/tmp/rustc2sPxVB/liblibc-ae22292566331366.rlib" "-Wl,--end-group" "/rust/lib/rustlib/arm-unknown-linux-musleabi/lib/libcompiler_builtins-1aed8fa9822aaf63.rlib" "-Wl,-Bdynamic" "/rust/lib/rustlib/arm-unknown-linux-musleabi/lib/self-contained/crtn.o"
  = note: /usr/local/bin/../lib/gcc/arm-linux-musleabi/9.2.0/../../../../arm-linux-musleabi/bin/ld: /tmp/rustc2sPxVB/libopenssl_sys-0f67a64037e617dd.rlib(drbg_lib.o): in function `RAND_DRBG_instantiate':
          drbg_lib.c:(.text.RAND_DRBG_instantiate+0x180): undefined reference to `__time64'
          /usr/local/bin/../lib/gcc/arm-linux-musleabi/9.2.0/../../../../arm-linux-musleabi/bin/ld: /tmp/rustc2sPxVB/libopenssl_sys-0f67a64037e617dd.rlib(drbg_lib.o): in function `RAND_DRBG_reseed':
          drbg_lib.c:(.text.RAND_DRBG_reseed+0x154): undefined reference to `__time64'
          /usr/local/bin/../lib/gcc/arm-linux-musleabi/9.2.0/../../../../arm-linux-musleabi/bin/ld: /tmp/rustc2sPxVB/libopenssl_sys-0f67a64037e617dd.rlib(drbg_lib.o): in function `RAND_DRBG_generate':
          drbg_lib.c:(.text.RAND_DRBG_generate+0x164): undefined reference to `__time64'
          /usr/local/bin/../lib/gcc/arm-linux-musleabi/9.2.0/../../../../arm-linux-musleabi/bin/ld: /tmp/rustc2sPxVB/libopenssl_sys-0f67a64037e617dd.rlib(rand_unix.o): in function `check_random_device':
          rand_unix.c:(.text.check_random_device+0x28): undefined reference to `__fstat_time64'
          /usr/local/bin/../lib/gcc/arm-linux-musleabi/9.2.0/../../../../arm-linux-musleabi/bin/ld: /tmp/rustc2sPxVB/libopenssl_sys-0f67a64037e617dd.rlib(rand_unix.o): in function `wait_random_seeded':
          rand_unix.c:(.text.wait_random_seeded+0x184): undefined reference to `__select_time64'
          /usr/local/bin/../lib/gcc/arm-linux-musleabi/9.2.0/../../../../arm-linux-musleabi/bin/ld: /tmp/rustc2sPxVB/libopenssl_sys-0f67a64037e617dd.rlib(rand_unix.o): in function `rand_pool_acquire_entropy':
          rand_unix.c:(.text.rand_pool_acquire_entropy+0x134): undefined reference to `__fstat_time64'
          /usr/local/bin/../lib/gcc/arm-linux-musleabi/9.2.0/../../../../arm-linux-musleabi/bin/ld: /tmp/rustc2sPxVB/libopenssl_sys-0f67a64037e617dd.rlib(rand_unix.o): in function `rand_pool_add_nonce_data':
          rand_unix.c:(.text.rand_pool_add_nonce_data+0x44): undefined reference to `__clock_gettime64'
          /usr/local/bin/../lib/gcc/arm-linux-musleabi/9.2.0/../../../../arm-linux-musleabi/bin/ld: rand_unix.c:(.text.rand_pool_add_nonce_data+0x88): undefined reference to `__gettimeofday_time64'
          /usr/local/bin/../lib/gcc/arm-linux-musleabi/9.2.0/../../../../arm-linux-musleabi/bin/ld: rand_unix.c:(.text.rand_pool_add_nonce_data+0xb0): undefined reference to `__time64'
          /usr/local/bin/../lib/gcc/arm-linux-musleabi/9.2.0/../../../../arm-linux-musleabi/bin/ld: /tmp/rustc2sPxVB/libopenssl_sys-0f67a64037e617dd.rlib(rand_unix.o): in function `rand_pool_add_additional_data':
          rand_unix.c:(.text.rand_pool_add_additional_data+0x74): undefined reference to `__clock_gettime64'
          /usr/local/bin/../lib/gcc/arm-linux-musleabi/9.2.0/../../../../arm-linux-musleabi/bin/ld: rand_unix.c:(.text.rand_pool_add_additional_data+0x9c): undefined reference to `__gettimeofday_time64'
          /usr/local/bin/../lib/gcc/arm-linux-musleabi/9.2.0/../../../../arm-linux-musleabi/bin/ld: rand_unix.c:(.text.rand_pool_add_additional_data+0xc4): undefined reference to `__time64'
          /usr/local/bin/../lib/gcc/arm-linux-musleabi/9.2.0/../../../../arm-linux-musleabi/bin/ld: /tmp/rustc2sPxVB/libopenssl_sys-0f67a64037e617dd.rlib(conf_def.o): in function `def_load_bio':
          conf_def.c:(.text.def_load_bio+0x5dc): undefined reference to `__stat_time64'
          collect2: error: ld returned 1 exit status

[nagisa]

The added deprecation notice is now making the libstd build to fail, as it depends on said type.

This means that libstd is either stuck on 0.2.79 for indeterminate amount of time or we need to figure out a way to support either version of musl or give users ability to specify the version of musl they target?

[JohnTitor]

This means that libstd is either stuck on 0.2.79 for indeterminate amount of time or we need to figure out a way to support either version of musl or give users ability to specify the version of musl they target?

It's related to #1412 but we don't have any policy for supported platforms. Yes, both ways are better than just changing the type (also cc #547).

[JohnTitor]

So, we currently detect FreeBSD version, like:

libc/build.rs

Lines 122 to 145 in 4c0a7e5

	fn which_freebsd() -> Option<i32> {
	let output = std::process::Command::new("freebsd-version").output().ok();
	if output.is_none() {
	return None;
	}
	let output = output.unwrap();
	if !output.status.success() {
	return None;
	}
	let stdout = String::from_utf8(output.stdout).ok();
	if stdout.is_none() {
	return None;
	}
	let stdout = stdout.unwrap();
	match &stdout {
	s if s.starts_with("10") => Some(10),
	s if s.starts_with("11") => Some(11),
	s if s.starts_with("12") => Some(12),
	s if s.starts_with("13") => Some(13),
	_ => None,
	}
	}

I wonder we could also detect musl version and separate time_t definition.

[ericonr]

I wonder we could also detect musl version and separate time_t definition.

How do you deal with the cross compilation case?

[arndb]

Note that this is not really musl specific, the change to 64-bit time_t needs to happen on all 32-bit implementations in order to have code working beyond year 2038. glibc on riscv uses 64-bit time_t, and patches for glibc and uclibc to convert all other architectures to make this a compile-time decision are in progress.

[pkgw]

It feels so silly to ask this, but ... what is the actual course of action here if I have FFI code that triggers this deprecation notice? Try to ensure that time_t doesn't appear in the FFI layer, i.e. add casts on the C side as appropriate to change time_t into int64_t/i64?

[rawler]

Echoing @pkgw here. What is the right course of action here? libc::time_t is deprecated on musl. Should I use some other type-alias? Hard-coding i64 is likely to also break on some targets, right? Should I use libc::time_t but suppress the warning?

[arndb]

Any use of time_t/timeval/timespec that does not match the libc-defined type will cause data corruption. On both musl and libc you can encounter both 32-bit and 64-bit types. With musl, this is purely dependent on the version of the library, i.e. musl-1.2 only allows compiling with a 64-bit time_t, while glibc allows both, depending on whether the _TIME_BITS macro was set to '64' when building the C code one is linking against, same as the _FILE_OFFSET_BITS macro for off_t and other types.

The only portable way to do this is to avoid any use of time_t, struct timeval, struct timespec, ino_t, blkcnt_t, as well as any types derived from these, such as struct stat, struct dirent, or struct rlimit when interfacing with C/C++ code.

[syrel]

emscripten changed time_t to 64bit in July 2022, see emscripten-core/emscripten#17393.
Probably could be another reason to reconsider this issue.