Should be built with 64-bit time_t on 32-bit GNU architectures
Historical 32-bit ABIs have a 32-bit signed time_t, which will overflow in early 2038. glibc 2.34 introduces an opt-in mechanism (defining _TIME_BITS=64
) which can be used to switch to alternative entry points with a 64-bit time_t.
In general, it is not safe to just recompile 32-bit libraries with a 64-bit time_t, because the size of time_t can affect the ABI - either directly, or via structs that contain a time_t, such as struct timeval.
However, for libdbus specifically, because we have a policy of not including system headers or using OS types in our public API/ABI, it should be possible to switch over transparently, resulting in a 32-bit libdbus that works correctly after 2038 and is a drop-in replacement for older versions.
Out of scope
If compiled against glibc older than 2.34, time_t will still be 32-bit. This is not fixable.
On non-GNU Unix platforms such as musl, Android and the BSDs, we cannot assume that defining _TIME_BITS=64
is the way to opt-in to a 64-bit time_t - depending on the platform, a 64-bit time_t might be the default anyway (a platform-wide ABI break) as it is in musl, or there might be no way to get a 64-bit time_t (which will fail in 2038 but that's not our problem), or there might be a different opt-in mechanism. Developers who are interested in running legacy 32-bit binaries on these platforms, or running these platforms on legacy 32-bit hardware, will need to contribute a tested solution for those platforms.
My understanding is that modern(ish) Windows toolchains use 64-bit timestamps by default, even when compiling 32-bit binaries, so we don't need to do anything special on Windows. If this is wrong, then someone who likes Windows will need to contribute a tested solution, similar to non-GNU Unix platforms.