Bug#905715: Directory for .gir (gobject-introspection) files? (Multi-Arch)

[W. Martin Borgert]

Hi Simon,

many thanks for taking the time to go through this bug report!
Very much appreciated!

On 2019-02-16 17:02, Simon McVittie wrote:
> Multiarch-qualified directories under /usr/share don't seem like they make
> much sense: the whole point of the $libdir/$datadir duality is that if
> files need to be different on some architectures, then the files should
> be in $libdir, not in $datadir.

True.

> My understanding is that GIR is intended to be a collection of
> machine-readable facts about the source code, rather than facts about
> the binary, which is why it's in /usr/share in the first place (unlike
> the typelib, which is architecture-dependent). However, those facts are
> partially derived from inspecting the binary, so can in principle end
> up different in rare cases, and presumably that is what's happened here.

(Just for myself in order to not forget it,) the six
GLib-2.0.gir variants are:

 - amd64
 - armel, armhf, i386, mipsel
 - arm64, mips64el, ppc64el
 - hurd-i386
 - mips
 - s390x

The differences are e.g. in how/whether GDoubleIEEE754,
GFloatIEEE754, G_VA_COPY_AS_ARRAY, GLIB_SIZEOF_LONG (4 vs 8
bytes), GUINTPTR_FORMAT (lu vs. u) etc. are defined.

Btw. Peter Pearse of Linaro found similar issues in 2011:
"Investigation of gobject introspection with a view to cross
compiling"
(https://wiki.linaro.org/PeterPearse/GobjectIntrospection)

The differences he found in Clutter-1.0.gir seem to be solved now,
the GLib-2.0.gir differences not.

> The program that generates GIR (g-ir-scanner) is architecture-independent
> Python code, so it's easy to say "gobject-introspection should look in
> its own $libdir/gir-1.0 in addition to $XDG_DATA_DIRS/gir-1.0", but
> probably harder to actually implement than you might think.

I found only one .gir file under $libdir in sid, only for ppc:

/usr/lib/powerpc-linux-gnu/mutter/ClutterX11-1.0.gir
/usr/lib/powerpc-linux-gnu/mutter/Clutter-1.0.gir

> One option for fixing this for buster, if it is considered to be urgent,
> is to investigate what the difference is and whether it can be eliminated,
> perhaps by wrapping the code that differs between architectures in
> #ifndef __GI_SCANNER__.

Sorry, here you lost me: In which code do you like to see the
conditionals? In glib?

> Another is to remove the M-A: same annotation.

I like to be able to cross-build certain packages. For my
usecase, I have to install libgirepository1.0-dev for multiple
architectures, because the package depends on it.

Cheers