[Bug] time_t64 causes regeneration to fail for gio-sys

[werdahias]

Debian in in the process of transitioning all libraries to 64-bit time to mitigate the year-2038 issue.
During this glib was renamed to libglib2.0-0t64. Now code regeneration fails:

RUST_BACKTRACE=full gir -o .
thread 'main' panicked at 'Incomplete library, unresolved: ["GLib.time_t"]', src/library_postprocessing.rs:69:9
stack backtrace:
   0:     0x5568503dfbfa - <unknown>
   1:     0x55685041bd9f - <unknown>
   2:     0x5568503e9a75 - <unknown>
   3:     0x5568503df9b5 - <unknown>
   4:     0x5568503e6b2e - <unknown>
   5:     0x5568503e67e9 - <unknown>
   6:     0x5568503e7081 - <unknown>
   7:     0x5568503dff29 - <unknown>
   8:     0x5568503dfd06 - <unknown>
   9:     0x5568503e6d82 - <unknown>
  10:     0x556850143a63 - <unknown>
  11:     0x55685024ac31 - <unknown>
  12:     0x556850164842 - <unknown>
  13:     0x556850144593 - <unknown>
  14:     0x5568501445b2 - <unknown>
  15:     0x5568503e6c81 - <unknown>
  16:     0x5568503fa18b - <unknown>
  17:     0x556850165e8c - <unknown>
  18:     0x7ffbf65456ca - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  19:     0x7ffbf6545785 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:360:3
  20:     0x556850143ec1 - <unknown>
  21:                0x0 - <unknown>

[sdroege]

You should do something about your debug symbols 😅

This is a known problem, we need to add support for time_t and other types to gir now that gobject-introspection is using them.

[sdroege]

You might also want to bring this up against the libc crate, which would block this on our side here. https://docs.rs/libc/latest/i686-unknown-linux-gnu/libc/type.time_t.html is unconditionally an i32, but somehow this needs to figure out that based on glibc versions and phase of moon, this is actually a i64. Not sure how that's supposed to be handled.

[sdroege]

See rust-lang/libc#3223 , that's I guess the closest just that Debian has everything even worse (see my comment).

The Debian wiki about the transition says

4963 are golang-*, librust-* and libghc-* which we can ignore, leaving 5360 packages

Which is clearly not true. We would here at build time have to decide if the glib library we link against has been compiled with 64 bit time_t or not, and the same will affect every other Rust crate that interfaces with a C library that exposes time_t in its API.

[werdahias]

Thanks for the insight. I guess I can just disable regeneration for now. While this doesn't resolve the issue at hand I can at least continue to prepare the gtk-rs update in debian. I forwarded the issue to the team; I don't have time to deal with this right now.

[sdroege]

Thanks. On the gir side here we can simply have it map to libc::time_t but it would be up to you to make sure that actually maps to what Debian expects. It's all a bit of a mess.

I might be missing something but this should also affect 3rd party / locally built C code on Debian.

I guess I can just disable regeneration for now

You should not regenerate against random versions of the gir files anyway. The ones that are known to work are the one tagged together with the releases. If you're using others then you're on your own, and the results will likely be API/ABI incompatible with the releases on crates.io.

[sdroege]

Also the current release is would not be ABI-compatible with a 64 bit time_t GLib C library on platforms where this wasn't the default before (and in extension any other Rust crate interfacing with a C library that has time_t in its API). It's going to cause memory corruption at runtime.

[sdroege]

@werdahias I just noticed that the libc crate is also planning a breaking 1.0 release very soon, and at that point things will be set in stone for a while. It would probably be good to set up some communication between Debian people who understand how this transition is supposed to work and the Rust project.

[werdahias]

CC @vorlonofportland

[sdroege]

FWIW, from how I understand Debian's implementation plan this will also randomly break in C libraries. If you build glib yourself (not via dpkg, which would set -D_TIME_BITS=64), you would get a GLib library that expects 32 bit time_t and which would have a different ABI than the one provided by the packages.

Similarly, someone building C code against GLib without setting -D_TIME_BITS=64 will get a 32 bit time_t and would pass that e.g. to g_date_set_time_t(). Depending on if that happens to be the GLib from the system or one built manually, this would either accidentally match the expected ABI or not.

From my understanding this is not just a "Rust" problem but also a "all C code not built via dpkg" (external code, proprietary code that you can't just rebuild, ...) problem.

[jamessan]

If you build glib yourself (not via dpkg, which would set -D_TIME_BITS=64), you would get a GLib library that expects 32 bit time_t and which would have a different ABI than the one provided by the packages.

Not quite. The toolchains also supply the flags by default:

Pass -D_TIME_BITS=64 together with -D_FILE_OFFSET_BITS=64 by default
on the 32bit architectures armel, armhf, hppa, m68k, mips, mipsel,
powerpc (-m32 only) and sh4.

If you build your own toolchain and then build random packages, then you can run into problems. :)

[sdroege]

Ah, I missed that the default toolchain flags are changed too (or it wasn't on the wiki page?). Thanks for the clarification. That makes it less bad. So you'd only run into problems with binary builds from before the change, and your own toolchains that don't have the right flags. That seems less bad.

So I guess the libc crate could check the target triplet and Debian version and switch based on that. And then implement the same for Fedora and others too.