Processed: Re: Bug#1066900: g-ir-compiler: generates incorrect typelib when cross-compiling with different type sizes
Processing control commands: > clone -1 -2 Bug #1066900 [gobject-introspection] g-ir-compiler: generates incorrect typelib when cross-compiling with different type sizes Bug 1066900 cloned as bug 1066904 > retitle -2 gi-compile-repository: generates incorrect typelib when > cross-compiling with different type sizes Bug #1066904 [gobject-introspection] g-ir-compiler: generates incorrect typelib when cross-compiling with different type sizes Changed Bug title to 'gi-compile-repository: generates incorrect typelib when cross-compiling with different type sizes' from 'g-ir-compiler: generates incorrect typelib when cross-compiling with different type sizes'. > reassign -2 libglib2.0-dev 2.79.3-1 Bug #1066904 [gobject-introspection] gi-compile-repository: generates incorrect typelib when cross-compiling with different type sizes Bug reassigned from package 'gobject-introspection' to 'libglib2.0-dev'. No longer marked as found in versions 1.78.1-7 and gobject-introspection/1.78.1-16. Ignoring request to alter fixed versions of bug #1066904 to the same values previously set Bug #1066904 [libglib2.0-dev] gi-compile-repository: generates incorrect typelib when cross-compiling with different type sizes Marked as found in versions glib2.0/2.79.3-1. > tags -2 = experimental Bug #1066904 [libglib2.0-dev] gi-compile-repository: generates incorrect typelib when cross-compiling with different type sizes Added tag(s) experimental; removed tag(s) sid and trixie. -- 1066900: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066900 1066904: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066904 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1066900: g-ir-compiler: generates incorrect typelib when cross-compiling with different type sizes
Control: clone -1 -2 Control: retitle -2 gi-compile-repository: generates incorrect typelib when cross-compiling with different type sizes Control: reassign -2 libglib2.0-dev 2.79.3-1 Control: tags -2 = experimental On Fri, 15 Mar 2024 at 07:48:17 +, Simon McVittie wrote: > 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. gi-compile-repository in libglib2.0-dev/experimental has the same issue, cloning the bug for that. > 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. Actually it looks like this is going to be a shorter path to correctness than the other approaches I described, so I'll probably go with this one. smcv
Bug#1066900: g-ir-compiler: generates incorrect typelib when cross-compiling with different type sizes
Package: gobject-introspection Version: 1.78.1-16 Severity: serious Justification: results in misbuilt packages X-Debbugs-Cc: debian-cr...@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
