Package: gobject-introspection
Version: 1.78.1-16
Severity: serious
Justification: results in misbuilt packages
X-Debbugs-Cc: debian-cross@lists.debian.org

When it converts GIR XML to binary typelib files, g-ir-compiler replaces abstract types such as int and gsize (size_t) with concrete types such as gint32 (int32_t) and guint64 (uint32_t). The way in which it does this
depends on the type sizes discovered at configure time when compiling g-ir-compiler.

This means that cross-compiling for an arm64 or riscv64 host on an amd64
build machine should be OK, but cross-compiling for armhf or i386 on amd64
will produce invalid typelibs. I am sorry that I didn't notice this sooner.

A crude solution to this would be to revert gobject-introspection and gobject-introspection-bin to be Multi-Arch: no, so that building typelibs
is no longer possible in cross-builds. [1]

A more refined version of that would be to change the relationship between gobject-introspection and gobject-introspection-bin so that instead of the current arrangement where the dependency is on a virtual package gobject-introspection-linux-little-endian, it would be on a virtual package that also reflects the word size in use: gobject-introspection-linux-lp64-little-endian or similar. This would
preserve the ability to cross-compile in only those situations where it
would be correct. [2]

A workaround to enable cross-compiling between word sizes would be to use
the host architecture g-ir-compiler, and run it via qemu-user.
Unfortunately this will greatly increase the amount of host-architecture
code that needs to be run via emulation.

In the short term, I'm going to do [1] or [2] as a matter of urgency,
to ensure that Ubuntu 24.04 doesn't ship with faulty cross-tools that
claim to work but actually do not. Any further improvement can be in-scope
for #1030223 "gobject-introspection: make cross-compilation possible".

If we do [2] then we will have to be extra-careful to distinguish between dissimilar ILP32 ABIs, because gobject-introspection currently hard-codes
that it thinks time_t is long and off_t is size_t, both of which happen
to be correct on LP64 and on i386, but neither of which is correct on
an ILP32 architecture that has transitioned to large file support and
64-bit time_t (such as armel and armhf in 2024) or an ILP32 architecture
that always had 64-bit off_t and time_t (such as x32).

I apologise for having been insufficiently careful when enabling this
feature.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)