-
Notifications
You must be signed in to change notification settings - Fork 5
Description
As you may or may not be aware there is an ongoing effort to support 64-bit time on 32-bit linux systems. This has been working it's way down through the ecosystem for the past few years, first the Linux kernel itself, then glibc, then distros.
On the kernel/glibc side this has been done in a manner similar to "large file support". Alternate versions of the functions and types have been added to Linux and Glibc and #ifdefs are used to select the 32-bit or 64-bit versions. However most other libraries do not have such "dual ABI" support, so libraries built with 64-bit time enabled may have ABI incompatibilities with those that don't. Debian have now enabled 64-bit time by default in their toolchain for all 32-bit ports except i386, and transistioned their library packages to the new ABI.
The rust libc crate now has support for 64-bit time on 32-bit GNU/linux systems, though it is disabled by default. It can be enabled by setting the environment variable "RUST_LIBC_UNSTABLE_GNU_TIME_BITS=64".
Unfortunately the support is not completely transparent to downstream software that uses libc. In particular there are the following changes, some of which unfortunately have a greater impact on rust code than they do on C code.
- The data types have obviously changed to accomodate the 64-bit time.
- Since many data structures and functions deal with both files and time it was decided that to reduce the number of variants of each function/data structure, that enabling 64-bit time would also require enabling large file support.
- A number of structures have had padding fields added or removed. The rust libc crate declares these fields as private, so structures that have added padding fields can no longer be constructed using struct literal syntax.
- Unfortunately glibc changes the tv_usec field in struct timespec to 64-bit but did not change the defintion of suseconds_t . This is recognised by the glibc developers as a mistake, but fixing it would be an ABI break ( https://sourceware.org/bugzilla/show_bug.cgi?id=31510 )
In Debian we are patching the clock-steering crate to accomodate these issues, our patch can be found at https://salsa.debian.org/rust-team/debcargo-conf/-/blob/fc300bdfec6ebdec8372c88ce279bbd8d408be29/src/clock-steering/debian/patches/time64.patch